Re: [Haskell-cafe] Cons of -XUndecidableInstances
On Mon, Jun 6, 2011 at 01:52, Yitzchak Gale g...@sefer.org wrote: Scott Lawrence wrote: You almost never want to use UndecidableInstances when writing practical programs in Haskell. Ah. That's what I wanted to know :P (Although it does seem to me - from looking around docs and the source - that GHC's rules for allowing certain combinations might be a bit too conservative - but then, I have next to no idea what I'm doing, so hey.) When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP. * hides behind book Your best bet is to step back and think again about the problem you are trying to solve. What is the best way to formulate the problem functionally? That will lead you in the right direction. Please feel free to share more details about what you are trying to do. We would be happy to help you work out some good directions. I'm modelling text in a markov-model-like way. I have an actual markov model (albeit one in which X_n depends on a fixed range X_n-1 .. X-n-k). I'm vaguely anticipating the presence of other models: class Model m a | m - a where lexemes :: m - Set a genFunc :: m - [a] - ProbDist a Having that working, I'm trying to estimate the information entropy of a model entropy :: (Model m) = m - Double (This is a slight simplification, since entropy needs a second argument precision to know when to terminate.) Which works well and fine - this function is pretty trivial to implement, on the assumption that Markov (the instance of Model described above) implements genFunc properly. But it happens not to - the array argument to genFunc must be the right size, otherwise an even probability distribution is used. So my OOP-infected mind wants to specialize 'entropy' for Markov: class Entropy d where entropy :: d - Double -- again, simplified Note that it's not (Entropy d a) because the type of the lexeme doesn't matter. Now, the problem code instance (Model m a) = Entropy m where entropy = undefined As you might have picked up, I suspect the part where I want to specialize entropy for Markov is where I mess up - but I'm not sure what to do. (To be clear, I expect to want to specialize entropy for other models too - the general function I have in mind would be horribly slow for many reasonable models.) Thanks. Regards, Yitz -- Scott Lawrence ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
Oops. I can just abandon the Entropy typeclass and put the function directly into Model, eh? Yeah, I think I'll do that... Supposing I didn't want to - any alternatives? Other instances of Entropy I might consider: instance (Eq a) = Entropy [a] instance (Eq a) = Entropy (Tree a) On Mon, Jun 6, 2011 at 02:13, Scott Lawrence byt...@gmail.com wrote: On Mon, Jun 6, 2011 at 01:52, Yitzchak Gale g...@sefer.org wrote: Scott Lawrence wrote: You almost never want to use UndecidableInstances when writing practical programs in Haskell. Ah. That's what I wanted to know :P (Although it does seem to me - from looking around docs and the source - that GHC's rules for allowing certain combinations might be a bit too conservative - but then, I have next to no idea what I'm doing, so hey.) When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP. * hides behind book Your best bet is to step back and think again about the problem you are trying to solve. What is the best way to formulate the problem functionally? That will lead you in the right direction. Please feel free to share more details about what you are trying to do. We would be happy to help you work out some good directions. I'm modelling text in a markov-model-like way. I have an actual markov model (albeit one in which X_n depends on a fixed range X_n-1 .. X-n-k). I'm vaguely anticipating the presence of other models: class Model m a | m - a where lexemes :: m - Set a genFunc :: m - [a] - ProbDist a Having that working, I'm trying to estimate the information entropy of a model entropy :: (Model m) = m - Double (This is a slight simplification, since entropy needs a second argument precision to know when to terminate.) Which works well and fine - this function is pretty trivial to implement, on the assumption that Markov (the instance of Model described above) implements genFunc properly. But it happens not to - the array argument to genFunc must be the right size, otherwise an even probability distribution is used. So my OOP-infected mind wants to specialize 'entropy' for Markov: class Entropy d where entropy :: d - Double -- again, simplified Note that it's not (Entropy d a) because the type of the lexeme doesn't matter. Now, the problem code instance (Model m a) = Entropy m where entropy = undefined As you might have picked up, I suspect the part where I want to specialize entropy for Markov is where I mess up - but I'm not sure what to do. (To be clear, I expect to want to specialize entropy for other models too - the general function I have in mind would be horribly slow for many reasonable models.) Thanks. Regards, Yitz -- Scott Lawrence -- Scott Lawrence ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
On Mon, Jun 6, 2011 at 7:52 AM, Yitzchak Gale g...@sefer.org wrote: Scott Lawrence wrote: More specifically, I have class Model m a | m - a where ... class Entropy d where ... instance (Model m a) = Entropy m where ... The first line requires MultiParamTypeClasses and FunctionalDependencies... the third requires UndecidableInstances... Is this likely to cause a problem? Yes. You almost never want to use UndecidableInstances when writing practical programs in Haskell. When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP. Your best bet is to step back and think again about the problem you are trying to solve. What is the best way to formulate the problem functionally? That will lead you in the right direction. Please feel free to share more details about what you are trying to do. We would be happy to help you work out some good directions. Are you sure you weren't thinking of OverlappingInstances here? I haven't seen as much scorn heaped upon Undecidable. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
Scott Lawrence wrote: I'm modelling text in a markov-model-like way. I have an actual markov model (albeit one in which X_n depends on a fixed range X_n-1 .. X-n-k). I'm vaguely anticipating the presence of other models: class Model m a | m - a where lexemes :: m - Set a genFunc :: m - [a] - ProbDist a Generally, we don't start out with a type class. Type classes are great for the special situations in which they are needed (although you can do pretty well without them even then), but first let's get the basic concepts. Perhaps a model is just a function: type Model a = Ord a = Set a - [a] - ProbDist a or something like that. Having that working, I'm trying to estimate the information entropy of a model entropy :: (Model m) = m - Double Perhaps just a function: entropy :: Model a - Double I still don't know enough details about what you're doing, so my types are probably off. But I hope you get the idea. If that's not general enough, you may introduce more functions, or some data types. Those give you a huge amount of power - remember that data types can take multiple type parameters (without any GHC extension), they can have functions as their parameters, etc. Or, perhaps you'll even get to the point where you'll need a type class, but that's pretty far down the road, and what you would need it for is very different than what a class is in OOP - they are different concepts. Hope this helps, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
On 06/06/2011 02:57 AM, Yitzchak Gale wrote: Generally, we don't start out with a type class. Type classes are great for the special situations in which they are needed (although you can do pretty well without them even then), but first let's get the basic concepts. Perhaps a model is just a function: type Model a = Ord a = Set a - [a] - ProbDist a or something like that. Erm... yeah, actually. But... this prevents me from storing more information in a Model in the future. While I don't really anticipate needing too (I can see this function covering all likely use cases), it does seem sorta restrictive. Having that working, I'm trying to estimate the information entropy of a model entropy :: (Model m) = m - Double Perhaps just a function: entropy :: Model a - Double I still don't know enough details about what you're doing, so my types are probably off. But I hope you get the idea. No, your types are right. If that's not general enough, you may introduce more functions, or some data types. Those give you a huge amount of power - remember that data types can take multiple type parameters (without any GHC extension), they can have functions as their parameters, etc. Or, perhaps you'll even get to the point where you'll need a type class, but that's pretty far down the road, and what you would need it for is very different than what a class is in OOP - they are different concepts. Oh, I understand the difference between a class and a typeclass. It's the difference between an interface and a typeclass that I apparently haven't grasped. Thanks. Hope this helps, Yitz signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
I wrote: You almost never want to use UndecidableInstances when writing practical programs in Haskell. When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP. Gábor Lehel wrote: Are you sure you weren't thinking of OverlappingInstances here? I haven't seen as much scorn heaped upon Undecidable. Sorry, I didn't mean to come across as heaping scorn on anything. :) Having come from OOP myself, I know that at first you don't realize the power and beauty of functional programming. The vast majority of programming problems have a beautiful solution without stepping outside of Haskell 98. One of the symptoms of thinking about a problem in OOP style rather than functionally is that you immediately find yourself needing all of those kinds of type system extensions, which just end up adding a huge amount of unneeded complexity. Once you are fluent and comfortable with functional thinking, you can learn about the many other tools and techniques that are available and when it is best to apply them. I must admit that even while designing and implementing large systems, I haven't found myself needing anything involving either UndecidableInstances or OverlappingInstances for several years. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
On 06/06/2011 03:13 AM, Scott Lawrence wrote:
I still don't know enough details about what you're doing,
so my types are probably off. But I hope you get the idea.
No, your types are right.
Or not.
type Model a = (Ord a) = Set a -- the set of lexemes
- [a] -- the original text to model
- [a] -- list of previous lexemes
- ProbDist a -- the next lexeme
and then
entropy :: Model a - Set a - [a] - Double
or perhaps more simply
entropy :: [a] - ProbDist a - Double
(Let me know if I'm doing something insane again - thanks.)
But this doesn't allow me to specialize for markov models. Seems to me
that to do that, I'd have to store data - and once I'm using a datatype
for markov models:
data Markov a = Markov
{ lexemeSet :: Set a
, matrix:: Map [a] (ProbDist a)
}
Then in order to get a consistent interface to various models, I'm going
to need a typeclass. (Which is required to use a single function name on
multiple datatypes, yes?)
I suppose the alternative is something like
data Model a = Markov {...} | OtherModel
Is that the functional solution? It seems to preclude the possibility of
separating the markov-specialized code and the other specialized code.
signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
Scott Lawrence wrote: But... this prevents me from storing more information in a Model in the future. While I don't really anticipate needing too (I can see this function covering all likely use cases), it does seem sorta restrictive. I tend not to think about storing information inside of things. I just write functions that do the computations I need - their types describe the desired inputs and outputs. Data types group them together into logical structures that reflect what I want to do. Where the information is coming from and where it is going then remains a totally independent issue. It is a different part of the program. That is actually more flexible, not restrictive. Kind of like the MVC design pattern. The IO monad, which keeps the parts of the program that interact with outside world separate, helps us think in this way. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Are casts required?
Are casts required to run the code below? If so why? Thanks, Pat -- Idetifiers for objects class (Integral i) = IDs i where startId :: i newId :: i - i newId i = succ i sameId, notSameId :: i - i - Bool -- Assertion is not easily expressible in Haskell -- notSameId i newId i = True sameId i j = i == j notSameId i j = not (sameId i j) startId = 1 instance IDs Integer where -- are casts need here? sameId (newId startId::Integer) 3 sameId (3::Integer) (4::Integer) notSameId (3::Integer) (newId (3::Integer)) This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
it won't be a pleasant choice to fork over a good chunk of money to Apple for the use of free software that they didn't develop. Whilst I acknowledge your painful situation, I'd like to rebut the idea that Apple stole someone else's free software and are selling it on. In fact, Apple developed, or paid for development of, quite a chunk of gcc: the objective-C front end and LLVM back end at least. In paying for XCode 4, you are getting a lot of proprietary code in addition to gcc. However, XCode 3 remains free to download, if you are a registered Apple developer. Registration is completely free of charge: http://developer.apple.com/programs/register/ You may find other links that make registration appear to cost $99 - but those are for the iOS or Mac developer programs, not the Apple developer program. The ones that charge money enable the right to publish software in the App Stores, which you do not need. I think you can download the free version of the XCode 3 installer, burn it to a DVD, and pass the DVD round your students. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
On Mon, Jun 6, 2011 at 7:52 AM, Yitzchak Gale g...@sefer.org wrote: You almost never want to use UndecidableInstances when writing practical programs in Haskell. Surprisingly enough, mtl uses UndecidableInstances, so almost every practical Haskell program uses it in one way or another. G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
Scott Lawrence wrote:
type Model a = (Ord a) = Set a -- the set of lexemes
- [a] -- the original text to model
- [a] -- list of previous lexemes
- ProbDist a -- the next lexeme
and then
entropy :: Model a - Set a - [a] - Double
or perhaps more simply
entropy :: [a] - ProbDist a - Double
Those all look reasonable.
Then in order to get a consistent interface to various models, I'm going
to need a typeclass. (Which is required to use a single function name on
multiple datatypes, yes?)
Why is it important to use the same function name? If you
have two different functions that do two different things, they
can have two different names.
If further down the line you need to write a function that is independent
of the model, the types of its arguments will show you what you
need to do.
I suppose the alternative is something like
data Model a = Markov {...} | OtherModel
Is that the functional solution? It seems to preclude the possibility of
separating the markov-specialized code and the other specialized code.
Right, it doesn't sound like that's the way to go here.
Regards,
YItz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
Gregory Collins wrote: Surprisingly enough, mtl uses UndecidableInstances, so almost every practical Haskell program uses it in one way or another. The library uses it, you don't use it directly in your program. Anyway, transformers does the job when you need to build on the basic monad transformers. You only need the UndecidableInstances stuff when you need to write functions that work for multiple different monad stacks and you are using type classes to define common interfaces. I find that to be a messy approach. There's almost always a better way. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
Chris Smith wrote: I had to abandon a plan to introduce Haskell in a class I taught this past semester [12 to 13 years old] because of issues with getting it installed on the Macintosh laptops that some of the students had. Truth is, you obviously don't need support for FFI development in that kind of situation. Hugs used to fill this niche. Now that Hugs isn't so well supported anymore, there is a void to be filled. On the other hand, Mark Lentczner has been doing a great job lately with the Haskell Platform installer for the Mac. So even though the full power of GHC isn't needed here, it is becoming really easy to get Haskell installed and working on a Mac in seconds. Apart from the need for XCode, which seems to be the last remaining issue. For now, at least, Malcolm's idea of an XCode 3 DVD seems to be a workaround. We'll see what happens with Lion though... Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 4/06/2011, at 5:12 AM, Andrew Coppin wrote: I'm curious to know why anybody thought that -- was a good comment marker in the first place. (I'm curious because Haskell isn't the only language to have made this strange choice.) Indeed. The Wikipedia lists Euphoria, Haskell, SQL, Ada, AppleScript, Eiffel, Lua, and VHDL. Presumably it was chosen for its resemblance to the em dash. SNOBOL had a neat hack. You could begin a comment with any of ⎡⎢⎣ making it possible to write blocks that looked like ⎡ A comment that ⎢ stretches over ⎣ several lines. APL's lamp symbol had the advantage of being wholly new and so having no prior conflicting uses. ⍝ has been in Unicode for a relatively long time. Bearing in mind that the characters that have been used to begin end of line comments include *, /, ;, !, #, %, and $, it's not clear that there's anything _that_ regrettable about -- . ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
This whole discussion is reminding me of Wadler's Law of Language Design [1], it's nice to see that in 15 years things haven't changed much! WADLER'S LAW OF LANGUAGE DESIGN In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position. 0. Semantics 1. Syntax 2. Lexical syntax 3. Lexical syntax of comments [1] http://www.informatik.uni-kiel.de/~curry,/listarchive/0017.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
On 6/06/2011, at 8:11 AM, Chris Smith wrote: That's interesting... whatever the reason, though, I concur that using Haskell seems much easier on Linux and Windows. I had to abandon a plan to introduce Haskell in a class I taught this past semester because of issues with getting it installed on the Macintosh laptops that some of the students had. You can always (1) Install VirtualBox -- it's free. (2) Set up an Ubuntu VM inside VirtualBox -- Ubuntu is also free. (3) Install Haskell in Ubuntu. I've done exactly that on the Mac laptop I use. I also have Haskell running under Mac OS with no special problems. It's very unfortunate that Haskell on Mac requires software which can neither be bundled in the install kit nor downloaded freely from elsewhere. Note that the price for XCode applies to *XCode*. It's not a price for *GCC*. Having XCode, I was about to download GCC 4.5, build it, and install it in my own ~/local directory. Presumably, having built it, I could have copied it somewhere else. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are casts required?
I always forget to reply all. Silly gmail. On Mon, Jun 6, 2011 at 2:07 AM, Ryan Ingram ryani.s...@gmail.com wrote: Hi Pat. There aren't any casts in that code. There are type annotations, but this is different than the idea of a cast like in C. For example ((3 :: Integer) :: Int) is a compile error. What you are seeing is that 3 has the type (forall a. Num a = a); that is, the literal '3' gets converted by the compiler into fromInteger (I# 3#) where 3# represents the machine word '3' and I# is the internal constructor Word# - Integer. class Num a where ... fromInteger :: Integer - a So by 'casting', or rather, providing a type annotation, you are specifying what instance of Num gets the call to 'fromInteger'. As to whether you *need* a type annotation: it depends. For example: foo () = sameId newId 3 the compiler will infer the type of 'foo' to be foo :: forall a. IDs a = () - a If you declare foo as a value, though, you run into the dreaded monomorphism restriction, and you might get a complaint from the compiler about ambiguity. foo2 = sameId newId 3 The monomorphism restriction forces values to be values; otherwise consider this -- the usual 'expensive' computation fib :: Num a = a - a fib 0 = 1 fib n = fib (n-1) + fib (n-2) x = fib 10 What's the type of x? Most generally, it's x :: Num a = a But this means that x will be recalculated every time it's used; the value can't be saved since x doesn't represent a single value but rather a separate value for each instance of Num. You are allowed to manually specify this type, but without it, the compiler says 'You meant this to be a value!' and forces it to a particular type if it can, or complains about ambiguity if it can't. As to how it does so, look up the rules for defaulting and monomorphism in the Haskell report. -- ryan On Mon, Jun 6, 2011 at 12:45 AM, Patrick Browne patrick.bro...@dit.iewrote: Are casts required to run the code below? If so why? Thanks, Pat -- Idetifiers for objects class (Integral i) = IDs i where startId :: i newId :: i - i newId i = succ i sameId, notSameId :: i - i - Bool -- Assertion is not easily expressible in Haskell -- notSameId i newId i = True sameId i j = i == j notSameId i j = not (sameId i j) startId = 1 instance IDs Integer where -- are casts need here? sameId (newId startId::Integer) 3 sameId (3::Integer) (4::Integer) notSameId (3::Integer) (newId (3::Integer)) This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ 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] Are casts required?
On Montag, 6. Juni 2011, 09:45, Patrick Browne wrote: Are casts required to run the code below? If so why? Thanks, Pat -- Idetifiers for objects class (Integral i) = IDs i where startId :: i newId :: i - i newId i = succ i sameId, notSameId :: i - i - Bool -- Assertion is not easily expressible in Haskell -- notSameId i newId i = True sameId i j = i == j notSameId i j = not (sameId i j) startId = 1 instance IDs Integer where -- are casts need here? sameId (newId startId::Integer) 3 sameId (3::Integer) (4::Integer) notSameId (3::Integer) (newId (3::Integer)) The type signatures (not casts) are needed if the compiler cannot determine the instance to use from the context. If you have e.g. a declaration foo :: Integer foo = whatever then sameId foo (newId 5) doesn't need a type signature since foo's type is known and determines the rest. Without such information, the compiler can't determine the instance it should use, so fails with an ambiguous type. [Some module might contain instance IDs Int where startId = 0 newId k = 3*k sameId i j = ((i `xor` j) .. 7) == 0 or something, then what?] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are casts required?
Hi Patrick,
On 06/06/2011 09:45 AM, Patrick Browne wrote:
Are casts required to run the code below?
If so why?
Thanks,
Pat
-- Idetifiers for objects
class (Integral i) = IDs i where
startId :: i
newId :: i - i
newId i = succ i
sameId, notSameId :: i - i - Bool
-- Assertion is not easily expressible in Haskell
-- notSameId i newId i = True
sameId i j = i == j
notSameId i j = not (sameId i j)
startId = 1
instance IDs Integer where
-- are casts need here?
sameId (newId startId::Integer) 3
I'll take this as an example. First of all, note that
WHAT YOU'VE WRITTEN IS NOT A CAST
, that is, if x is an Int, then x :: Double is a type error. What the
'::' does is (in this situation) that it specializes the type of a
polymorphic value.
In GHCi, omitting the ':: Integer' part, I get
*Main let x1' = sameId (newId startId) 3
interactive:1:10:
Ambiguous type variable `i' in the constraint:
`IDs i' arising from a use of `sameId' at interactive:1:10-33
Probable fix: add a type signature that fixes these type variable(s)
Let's take the above expression apart:
We have:
*Main :t newId startId
newId startId :: (IDs i) = i
*Main :t 3
3 :: (Num t) = t
*Main :t sameId
sameId :: (IDs i) = i - i - Bool
Now, when trying to evaluating your expression, the machine ultimately
has to know what (newId startId) and 3 are. This, of course, depends on
the type chosen for i and t, respectively.
For example, if I define the following instance:
instance IDs Int where
startId = 2
we have:
*Main sameId (newId startId :: Integer) 3
False
*Main sameId (newId startId :: Int) 3
True
, so the result type clearly depends on the types chosen.
But, lacking an explicit signature, there is no way for the machine to
tell which types should be used, in particular as the information which
types were chosen is completely lost in the resulting type 'Bool'.
The example above does not look as if it was created to illustrate your
problem. Then however, note that you don't have to use a class if you
don't expect people to overwrite your default implementations. Normal
Functions are sufficient:
-- I always want this
{-# LANGUAGE NoMonomorphismRestriction #-}
startId :: (Integral i) = i
startId = 1
newId :: (Integral i) = i - i
newId = succ
sameId, notSameId :: (Integral i) = i - i - Bool
sameId = (==)
notSameId i j = not $ sameId i j
Ok, now this works even without the signatures:
*Main sameId (newId startId) 3
False
, which is probably caused by defaulting on the top level (IIRC, an
unresolved Integral type variable defaults to Integer. Don't have the
documentation at hand right now.) like this:
*Main let i3 = 3 :: (Integral x = x)
*Main :t i3
i3 :: Integer
and the same thing happens on the (newId startId) side, too.
As one last remark, your original problem that caused the Ambiguous
type variable error looks very similar to the well-known (show . read)
problem.
-- Steffen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HUnit false-positive stumper
On 6 June 2011 02:34, KQ qu...@sparq.org wrote: The shock here is that there was only one failure, whereas the False ~=? True should have failed. I'm not sure, but at a glance it looks you might have the usual problem where compiling your test with optimisations means that GHC optimises away the test failure. This is a known problem. If you compile with -fno-state-hack (or -O0) it should work. Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are casts required?
On Montag, 6. Juni 2011, 11:08, Ryan Ingram wrote: Hi Pat. There aren't any casts in that code. There are type annotations, but this is different than the idea of a cast like in C. For example ((3 :: Integer) :: Int) is a compile error. What you are seeing is that 3 has the type (forall a. Num a = a); that is, the literal '3' gets converted by the compiler into fromInteger (I# 3#) where 3# represents the machine word '3' and I# is the internal constructor Word# - Integer. Close, but not correct. In GHC, we have data Int = I# Int# and (if we're using integer-gmp) data Integer = S# Int# | J# Int# ByteArray# So, 3# is the *signed* machine int '3' and you'd get fromInteger (S# 3#) using the literal '3'. class Num a where ... fromInteger :: Integer - a So by 'casting', or rather, providing a type annotation, you are specifying what instance of Num gets the call to 'fromInteger'. As to whether you need a type annotation: it depends. For example: foo () = sameId newId 3 Types don't match, sameId :: IDs i = i - i - Bool newId :: IDs i = i - i Make that foo () = startId to get Ryan's types. the compiler will infer the type of 'foo' to be foo :: forall a. IDs a = () - a If you declare foo as a value, though, you run into the dreaded monomorphism restriction, and you might get a complaint from the compiler about ambiguity. foo2 = sameId newId 3 And foo2 = startId The monomorphism restriction forces values to be values; otherwise consider this -- the usual 'expensive' computation fib :: Num a = a - a fib 0 = 1 fib n = fib (n-1) + fib (n-2) x = fib 10 What's the type of x? Most generally, it's x :: Num a = a But this means that x will be recalculated every time it's used; the value can't be saved since x doesn't represent a single value but rather a separate value for each instance of Num. You are allowed to manually specify this type, but without it, the compiler says 'You meant this to be a value!' and forces it to a particular type if it can, or complains about ambiguity if it can't. As to how it does so, look up the rules for defaulting and monomorphism in the Haskell report. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
Nicolas Wu schrieb: This whole discussion is reminding me of Wadler's Law of Language Design [1], it's nice to see that in 15 years things haven't changed much! WADLER'S LAW OF LANGUAGE DESIGN In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position. 0. Semantics 1. Syntax 2. Lexical syntax 3. Lexical syntax of comments [1] http://www.informatik.uni-kiel.de/~curry,/listarchive/0017.html It's the first time, that I see a discussion about comment syntax in Haskell-Cafe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
I would be fantastic if XCode wasn't a dependency. As well as the inconvenience it also weighs in at around 5G (IIRC) of space which is still somewhat significant. Not to detract at all from the work of the wonderful GHC and Haskell Platform contributors in any way. For me it would just make it that much easier to convince mac-using friends to give Haskell a try. On Mon, Jun 6, 2011 at 4:49 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: On 6/06/2011, at 8:11 AM, Chris Smith wrote: That's interesting... whatever the reason, though, I concur that using Haskell seems much easier on Linux and Windows. I had to abandon a plan to introduce Haskell in a class I taught this past semester because of issues with getting it installed on the Macintosh laptops that some of the students had. You can always (1) Install VirtualBox -- it's free. (2) Set up an Ubuntu VM inside VirtualBox -- Ubuntu is also free. (3) Install Haskell in Ubuntu. I've done exactly that on the Mac laptop I use. I also have Haskell running under Mac OS with no special problems. It's very unfortunate that Haskell on Mac requires software which can neither be bundled in the install kit nor downloaded freely from elsewhere. Note that the price for XCode applies to *XCode*. It's not a price for *GCC*. Having XCode, I was about to download GCC 4.5, build it, and install it in my own ~/local directory. Presumably, having built it, I could have copied it somewhere else. ___ 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] How to install GhC on a Mac without registering?
On Mon, 2011-06-06 at 08:51 +0100, Malcolm Wallace wrote: In paying for XCode 4, you are getting a lot of proprietary code in addition to gcc. True... but not *using* it. However, XCode 3 remains free to download, if you are a registered Apple developer. Registration is completely free of charge: http://developer.apple.com/programs/register/ Ah, thank you! I was indeed under the impression that the registration needed here was the same one that costs $99. It's good to know that's not true, and practically speaking, this at least makes it possible to get things set up on Macs for my class. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote: I would be fantastic if XCode wasn't a dependency. ... Not to detract at all from the work of the wonderful GHC and Haskell Platform contributors in any way. For me it would just make it that much easier to convince mac-using friends to give Haskell a try. The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
From: Chris Smith cdsm...@gmail.com June 6, 2011 8:58 AM On Mon, 2011-06-06 at 08:51 +0100, Malcolm Wallace wrote: In paying for XCode 4, you are getting a lot of proprietary code in addition to gcc. True... but not *using* it. However, XCode 3 remains free to download, if you are a registered Apple developer. Registration is completely free of charge: http://developer.apple.com/programs/register/ Ah, thank you! I was indeed under the impression that the registration needed here was the same one that costs $99. It's good to know that's not true, and practically speaking, this at least makes it possible to get things set up on Macs for my class. There do seem to be source releases for the open source components http://www.opensource.apple.com/release/developer-tools-40/ Maybe someone interested could build a self-contained gcc to include with the Haskell Platform, as on Windows. Neither owning nor regularly using a Mac, I just looked into this after seeing the surprising claim that charging for Xcode 4 was motivated by accounting requirements. Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
Isn't gcc just used for its assembler and object file creation, these days, now that via-C is deprecated? Or are there other parts of it that are needed? On Mon, Jun 6, 2011 at 10:47 AM, Malcolm Wallace malcolm.wall...@me.comwrote: On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote: I would be fantastic if XCode wasn't a dependency. ... Not to detract at all from the work of the wonderful GHC and Haskell Platform contributors in any way. For me it would just make it that much easier to convince mac-using friends to give Haskell a try. The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) Regards, Malcolm ___ 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] How to install GhC on a Mac without registering?
On 06/06/11 15:57, Daniel Peebles wrote: Isn't gcc just used for its assembler and object file creation, these days, now that via-C is deprecated? Or are there other parts of it that are needed? The C compiler is needed to support foreign export and foreign import wrapper, and we also generate C fragments for some initialisation code now (in 7.2.1) as part of some changes I made to the way module initialisation is done. The C compiler is also used to support -rtsopts, which requires compiling a small C file and linking it into the binary. It's sometimes handy to be able to compile C files with GHC, if you're not using Cabal. Cheers, Simon On Mon, Jun 6, 2011 at 10:47 AM, Malcolm Wallace malcolm.wall...@me.com mailto:malcolm.wall...@me.com wrote: On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote: I would be fantastic if XCode wasn't a dependency. ... Not to detract at all from the work of the wonderful GHC and Haskell Platform contributors in any way. For me it would just make it that much easier to convince mac-using friends to give Haskell a try. The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list glasgow-haskell-us...@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HUnit false-positive stumper
On 06/06/2011 10:23, Max Bolingbroke wrote: On 6 June 2011 02:34, KQ qu...@sparq.org wrote: The shock here is that there was only one failure, whereas the False ~=? True should have failed. I'm not sure, but at a glance it looks you might have the usual problem where compiling your test with optimisations means that GHC optimises away the test failure. This is a known problem. If you compile with -fno-state-hack (or -O0) it should work. Can anyone expand on this? It seems odd to me that, an optimisation that causes some programs to behave incorrectly is switched on as part of the optimisation suites. Especially as there's no warning in the manual (or at least, not under http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.html#options-f which seems like the obvious place) I found some references to -fno-state-hack being required when compiling without occasionally causes bad performance, and also to prevent unsafePerformIOs being optimised away, but these seem a lot less bad. (Performance changes aren't as bad as correctness, and unsafePerformIO is known to be, well unsafe). I also found quite a few references to how beneficial this optimisation is to IO code, but I wonder if program correctness is a price worth paying. Or is this bad behaviour due to HUnit doing something unsafe? Regards, Jim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Maybe use advice
I'm writing an optimisation routine using Uniplate. Unfortunately, a sub-function I'm writing is getting caught in an infinite loop because it doesn't return Nothing when there are no optimisations left. I'd like a way to move the last Just into f, but this makes recursion very messy. I was wondering if there was a nice way to use something like the Monad or Applicative instance to help here. -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = Just $ Modifier (Changes (f l)) i where f (Scale x y : Scale x' y' : l) = f $ Scale (x*x') (y*y') : f l f (Translate x y : Translate x' y' : l) = f $ Translate (x+x') (y+y') : f l f (Rotatex : Rotatex': l) = f $ Rotate(x+x'): f l f l = l Any ideas? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HUnit false-positive stumper
On 6 June 2011 16:18, Jimbo Massive jimbo.massive-hask...@xyxyx.org wrote: Or is this bad behaviour due to HUnit doing something unsafe? I think it may be related to this bug: http://hackage.haskell.org/trac/ghc/ticket/5129 The suggested fix is to change HUnit to define assertFailure with throwIO, but the latest source code still uses throw: http://hackage.haskell.org/trac/ghc/ticket/5129 So this could very well be a HUnit bug. Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HUnit false-positive stumper
On 6 June 2011 16:43, Max Bolingbroke batterseapo...@hotmail.com wrote: The suggested fix is to change HUnit to define assertFailure with throwIO, but the latest source code still uses throw: Err, I mean http://hackage.haskell.org/packages/archive/HUnit/latest/doc/html/src/Test-HUnit-Lang.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HUnit false-positive stumper
That sounds very applicable to my issue (and unfortunately my googling missed this, ergo my consult of haskell-cafe uberwissenmensch). When I again have access to the aforementioned Mac this evening I'll try both disabling optimizations and a tweaked HUnit to see if that resolves the problem and report back then. -KQ Quoting Max Bolingbroke batterseapo...@hotmail.com: On 6 June 2011 16:18, Jimbo Massive jimbo.massive-hask...@xyxyx.org wrote: Or is this bad behaviour due to HUnit doing something unsafe? I think it may be related to this bug: http://hackage.haskell.org/trac/ghc/ticket/5129 The suggested fix is to change HUnit to define assertFailure with throwIO, but the latest source code still uses throw: http://hackage.haskell.org/trac/ghc/ticket/5129 So this could very well be a HUnit bug. Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - This mail sent through IMP: http://horde.org/imp/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can it be proven there are no intermediate useful type classes between Applicative Functors Monads?
On Sun, Jun 05, 2011 at 12:51:47PM -0700, KC wrote: If new intermediate classes crop up then there would be no point in fixing class (Applicative m) = Monad m where since it would have to be changed if new intermediate classes are found. There actually is at least one intermediate class that I know of, class Applicative m = Branching m where branch :: m Bool - m a - m a - m a subject to the laws branch (m * pure True) t f == m * t branch (m * pure False) t f == m * f or something like that. The idea is that Applicative computations have a fixed structure which is independent of intermediate results; Monad computations correspond to (potentially) infinitely branching trees, since intermediate results (which could be of an infinite-sized type) can be used to compute the next action; but Branching computations correspond to *finitely* branching trees, since future computation can depend on intermediate results, but only one binary choice at a time. However, I doubt this qualifies as useful no matter how you define it, although I would not be sad to be proven wrong. In any case, I think it is ethically indefensible to procrastinate in doing something good just in case you might miss an opportunity to do something perfect later. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: dtd-text DTD parser and renderer, V0.1.1.0
The dtd-text package[1] provides a parser and renderer for XML DTDs. It implements most of the parts of the W3C XML specification relating to DTDs, and is compatible with versions 1.0 and 1.1 of the specification.[2] The parser and renderer operate on Haskell DTD objects from the dtd-types[3] package. The parser is based on the attoparsec-text[4] parser library. Version 0.1.1.0 adds the first preliminary version of the renderer, based on the blaze-builder[5] package. Synopsis: -- Parse a DTD without parameter entity resolution. -- See the attoparsec-text package for information -- about how to use this parser. dtd :: Parse DTD -- Parse a DTD from a Data.Text.Lazy while resolving -- references to internal parameter entities. If you -- are not sure which interface to use, use this one. dtdParse :: L.Text - DTD -- Parse a DTD from a Data.Text.Lazy while resolving -- references to internal and external parameter entities. -- Supply the values of the external parameter references -- using a SymTable, where type SymTable = M.Map Text L.Text dtdParseWithExtern :: SymTable - L.Text - DTD -- Create a builder to render a DTD. -- See the blaze-builder package for information -- about how to use this builder. buildDTD :: DTD - Builder Enjoy, Yitz [1] http://hackage.haskell.org/package/dtd-text [2] http://www.w3.org/TR/2008/REC-xml-20081126/ [3] http://hackage.haskell.org/package/dtd-types [4] http://hackage.haskell.org/package/attoparsec-text [5] http://hackage.haskell.org/package/blaze-builder ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: dtd-text DTD parser, V0.1.0.0
I wrote: I really should have edited the Cabal description of this package before I uploaded it. Max Rabkin wrote: Could you upload a bugfix version with an accurate description? This could be very frustrating to a random hackage-brower who hasn't read the announcement (or me, in a few months, having forgotten this announcement). Well, it was up for a day anyway while I was offline. I fixed it by making the description come true - I've uploaded a new version that does have the renderer. Hope that's OK. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
Bearing in mind that the characters that have been used to begin
end of line comments include *, /, ;, !, #, %, and $, it's not
clear that there's anything _that_ regrettable about -- .
Recall that the problem is not with isolated characters, but whole strings.
-- a is a comment, --a is a comment, but ---a is not. That is done
wrong. Either make them all comments, or make them none comments.
{- a -} is a comment, {-a-} is a comment, {--a--} is a comment,
{---} is a comment. That is done right. Similarly, in C, /***/ is a
comment; in C++, /// is a comment (compare with Haskell's ---!); in
LaTeX, %%@#$^* is a comment. These are all done right. Consistently.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Attoparsec concatenating combinator
On Sun, Jun 5, 2011 at 11:00 AM, Yitzchak Gale g...@sefer.org wrote: If behind the scenes the concat is copying directly from slices of the original input, then no, in principle we're not saving much then. I thought there were *two* copies going on. If you're using the specialised functions like attoparsec's takeWhile, then all they do is return a view into the underlying array. No copying occurs until the concat itself. Now that I think of it: in principle, you could write a specialised concat that would check the pointer/offset/length combinations of its arguments and, if they all abutted perfectly, would just return a new view into that same array, sans copying. (You'd have to hide it behind unsafePerformIO, of course.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can it be proven there are no intermediate useful type classes between Applicative Functors Monads?
On Mon, Jun 6, 2011 at 9:19 AM, Brent Yorgey byor...@seas.upenn.edu wrote: On Sun, Jun 05, 2011 at 12:51:47PM -0700, KC wrote: If new intermediate classes crop up then there would be no point in fixing class (Applicative m) = Monad m where since it would have to be changed if new intermediate classes are found. There actually is at least one intermediate class that I know of, class Applicative m = Branching m where branch :: m Bool - m a - m a - m a subject to the laws branch (m * pure True) t f == m * t branch (m * pure False) t f == m * f or something like that. The idea is that Applicative computations have a fixed structure which is independent of intermediate results; Monad computations correspond to (potentially) infinitely branching trees, since intermediate results (which could be of an infinite-sized type) can be used to compute the next action; but Branching computations correspond to *finitely* branching trees, since future computation can depend on intermediate results, but only one binary choice at a time. However, I doubt this qualifies as useful no matter how you define it, although I would not be sad to be proven wrong. In any case, I think it is ethically indefensible to procrastinate in doing something good just in case you might miss an opportunity to do something perfect later. -Brent I take it you would prefer the following signature class (Applicative m) = Monad m where -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On Montag, 6. Juni 2011, 19:08, Albert Y. C. Lai wrote:
Bearing in mind that the characters that have been used to begin
end of line comments include *, /, ;, !, #, %, and $, it's not
clear that there's anything _that_ regrettable about -- .
Recall that the problem is not with isolated characters, but whole
strings.
-- a is a comment, --a is a comment, but ---a is not.
It is. Report, section 2.3:
'An ordinary comment begins with a sequence of two or more consecutive
dashes (e.g. --) and extends to the following newline. The sequence of
dashes must not form part of a legal lexeme. For example, “--” or “|--” do
not begin a comment, because both of these are legal lexemes; however “--
foo” does start a comment.'
A sequence of two or more dashes does not begin an end-of-line-comment if
and only if it is part of a lexeme containing only symbols and at least one
non-dash symbol.
It might be a good idea to include whitespace in the comment delimiter:
end-of-line-comment is begun by whitespace--{-}whitespace.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 2011-06-06 13:08 -0400, Albert Y. C. Lai wrote: Recall that the problem is not with isolated characters, but whole strings. [...] in LaTeX, %%@#$^* is a comment. This example probably does not help your position. Since (La)TeX allows the comment character to be changed at any time, the above is not necessarily a comment. Furthermore, even with the default character classifications, \% does not introduce a comment. \% not introducing a comment in (La)TeX doesn't seem a whole lot different from --- not introducing a comment in Haskell. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 2011-06-06 13:39 -0400, Nick Bowler wrote: On 2011-06-06 13:08 -0400, Albert Y. C. Lai wrote: Recall that the problem is not with isolated characters, but whole strings. [...] in LaTeX, %%@#$^* is a comment. This example probably does not help your position. Since (La)TeX allows the comment character to be changed at any time, the above is not necessarily a comment. Furthermore, even with the default character classifications, \% does not introduce a comment. \% not introducing a comment in (La)TeX doesn't seem a whole lot different from --- not introducing a comment in Haskell. And as was pointed out elsethread, --- /does/ in fact introduce a comment in Haskell. So the above should read: \% ... doesn't seem a whole lot different from --| ... -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 11-06-06 01:34 PM, Daniel Fischer wrote: On Montag, 6. Juni 2011, 19:08, Albert Y. C. Lai wrote: Recall that the problem is not with isolated characters, but whole strings. -- a is a comment, --a is a comment, but ---a is not. It is. Report, section 2.3: Sorry. Then --| is not a comment. In C++, //| is a comment (compare with Haskell's --|!). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
On Mon, Jun 6, 2011 at 16:47, Malcolm Wallace wrote: The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) I would be in favor of this -- assuming it didn't create new problems -- especially if it meant the latest GHC installer could be used on older versions of Mac OS X. The Windows installer still works for Windows 2000, but the Mac installer requires the Snow Leopard. Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On Monday 06 June 2011, 19:51:44, Albert Y. C. Lai wrote: On 11-06-06 01:34 PM, Daniel Fischer wrote: On Montag, 6. Juni 2011, 19:08, Albert Y. C. Lai wrote: Recall that the problem is not with isolated characters, but whole strings. -- a is a comment, --a is a comment, but ---a is not. It is. Report, section 2.3: Sorry. Then --| is not a comment. In C++, //| is a comment (compare with Haskell's --|!). True. But then, to my knowledge, C++ has a fixed small set of operators, so the problem of a comment delimiter possibly being part of a different lexeme doesn't arise there. There is, however, a somewhat similar problem in C and C++: z = *x/*y; // oops */ Back to Haskell: I agree, the choice of the comment delimiter was not the best in light of the possibility to define operators containing it as a substring. But changing it to have --| start a comment too might break too much code (and eliminating -- as a comment starter would certainly break far too much code). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe use advice
On Mon, 2011-06-06 at 23:38 +0800, Lyndon Maydwell wrote: I'm writing an optimisation routine using Uniplate. Unfortunately, a sub-function I'm writing is getting caught in an infinite loop because it doesn't return Nothing when there are no optimisations left. I'd like a way to move the last Just into f, but this makes recursion very messy. I was wondering if there was a nice way to use something like the Monad or Applicative instance to help here. -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = Just $ Modifier (Changes (f l)) i where f (Scale x y : Scale x' y' : l) = f $ Scale (x*x') (y*y') : f l f (Translate x y : Translate x' y' : l) = f $ Translate (x+x') (y+y') : f l f (Rotatex : Rotatex': l) = f $ Rotate(x+x'): f l f l = l Any ideas? Something like: ... f (Rotatex : Rotatex': l) = Just $ f (Rotate (x+x') : fromMaybe l (f l)) f l = Nothing -- As far as I understend Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
Back to Haskell: I agree, the choice of the comment delimiter was not the best in light of the possibility to define operators containing it as a substring. But changing it to have --| start a comment too might break too much code (and eliminating -- as a comment starter would certainly break far too much code). I like that you have to put a space in for haddock comments. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can it be proven there are no intermediate useful type classes between Applicative Functors Monads?
On Mon, Jun 6, 2011 at 12:19 PM, Brent Yorgey byor...@seas.upenn.edu wrote:
The idea is that Applicative computations
have a fixed structure which is independent of intermediate results;
Monad computations correspond to (potentially) infinitely branching
trees, since intermediate results (which could be of an infinite-sized
type) can be used to compute the next action; but Branching
computations correspond to *finitely* branching trees, since future
computation can depend on intermediate results, but only one binary
choice at a time.
Is this truly an intermediate variety of structure, though? Or just
different operations on existing structures? With Applicative, there
are examples of useful structures that truly can't work as a Monad,
the usual example being arbitrary lists with liftA2 (,) giving zip,
not the cartesian product. Do you know any examples of both:
1) Something with a viable instance for Branching, but either no Monad
instance, or multiple distinct Monad instances compatible with the
Branching instance
2) Same as above, except for a viable Applicative instance without a
single obvious Branching instance
In other words, an implementation of branch for some type that's not
obviously equivalent to one of these definitions:
branchMonad mb t f = do { b - mb; if b then t else f }
branchApplicative = liftA3 (\b t f - if b then t else f)
I can certainly believe that such an example exists, but I can't think
of one. In particular, it doesn't seem to be possible for ZipList (the
obvious almost-instance does not quite do what you may think it does).
If memory serves me, sometimes the limited nature of Applicative
allows a more efficient implementation than Monad, and in such cases I
can easily believe that branch could be made more efficient than the
generic form based on Monad. But that's not terribly persuasive for
creating a type class, I don't think.
- C.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe use advice
(missed including cafe) f :: [Modification] - Maybe [Modification] and f _ = Just $ f ... are incompatible I managed to get the behaviour I'm after with the use of Either, but this really is messy: -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = g (f (Left l)) where g (Right l) = Just $ Modifier (Changes l) i g (Left l) = Nothing f (Left (Scale x y : Scale x' y' : l)) = f $ Right $ Scale (x*x') (y*y') : h (f $ Left l) f (Left (Translate x y : Translate x' y' : l)) = f $ Right $ Translate (x+x') (y+y') : h (f $ Left l) f (Left (Rotatex : Rotatex': l)) = f $ Right $ Rotate(x+x'): h (f $ Left l) f x = x h (Left l) = l h (Right l) = l On Tue, Jun 7, 2011 at 3:11 AM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: On Mon, 2011-06-06 at 23:38 +0800, Lyndon Maydwell wrote: I'm writing an optimisation routine using Uniplate. Unfortunately, a sub-function I'm writing is getting caught in an infinite loop because it doesn't return Nothing when there are no optimisations left. I'd like a way to move the last Just into f, but this makes recursion very messy. I was wondering if there was a nice way to use something like the Monad or Applicative instance to help here. -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = Just $ Modifier (Changes (f l)) i where f (Scale x y : Scale x' y' : l) = f $ Scale (x*x') (y*y') : f l f (Translate x y : Translate x' y' : l) = f $ Translate (x+x') (y+y') : f l f (Rotate x : Rotate x' : l) = f $ Rotate (x+x') : f l f l = l Any ideas? Something like: ... f (Rotate x : Rotate x' : l) = Just $ f (Rotate (x+x') : fromMaybe l (f l)) f l = Nothing -- As far as I understend Regards ___ 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] Maybe use advice
On Tue, 2011-06-07 at 04:09 +0800, Lyndon Maydwell wrote: (missed including cafe) f :: [Modification] - Maybe [Modification] and f _ = Just $ f ... are incompatible My bad: f ... = let cs' = (Rotate (x+x') : fromMaybe cs (f cs)) in fromMaybe cs (f cs) Or refactoring it: g l = fromMaybe l (f l) f (Rotatex : Rotatex': cs) = g (Rotate (x+x') : g cs) Regards I managed to get the behaviour I'm after with the use of Either, but this really is messy: -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = g (f (Left l)) where g (Right l) = Just $ Modifier (Changes l) i g (Left l) = Nothing f (Left (Scale x y : Scale x' y' : l)) = f $ Right $ Scale (x*x') (y*y') : h (f $ Left l) f (Left (Translate x y : Translate x' y' : l)) = f $ Right $ Translate (x+x') (y+y') : h (f $ Left l) f (Left (Rotatex : Rotatex': l)) = f $ Right $ Rotate(x+x'): h (f $ Left l) f x = x h (Left l) = l h (Right l) = l On Tue, Jun 7, 2011 at 3:11 AM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: On Mon, 2011-06-06 at 23:38 +0800, Lyndon Maydwell wrote: I'm writing an optimisation routine using Uniplate. Unfortunately, a sub-function I'm writing is getting caught in an infinite loop because it doesn't return Nothing when there are no optimisations left. I'd like a way to move the last Just into f, but this makes recursion very messy. I was wondering if there was a nice way to use something like the Monad or Applicative instance to help here. -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = Just $ Modifier (Changes (f l)) i where f (Scale x y : Scale x' y' : l) = f $ Scale (x*x') (y*y') : f l f (Translate x y : Translate x' y' : l) = f $ Translate (x+x') (y+y') : f l f (Rotatex : Rotatex': l) = f $ Rotate(x+x') : f l f l = l Any ideas? Something like: ... f (Rotatex : Rotatex': l) = Just $ f (Rotate (x+x') : fromMaybe l (f l)) f l = Nothing -- As far as I understend Regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
Am 23.05.2011 13:32, schrieb Simon Marlow: On 18/05/2011 19:22, Jason Dagit wrote: On Wed, May 18, 2011 at 2:50 AM, John Sneerjohnsn...@operamail.com wrote: Hello all, I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed how to where is described building of Haskell Platform natively to 64bit Windows? If you figure out how to do this, I would like to know as well. I could also benefit from 64bit Haskell on windows. There is no port of GHC to 64-bit Windows yet. Various people have expressed an interest in having one, but it is a significant chunk of work to implement (plus extra work to maintain and build distributions), so we don't have any plans to do it in the short term. You can track progress (or lack thereof) by adding your email to the CC on the ticket: http://hackage.haskell.org/trac/ghc/ticket/1884 If you want to help out, join cvs-...@haskell.org and we can help with pointers to what needs to be done. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Hi, Just to double check: that means, today it's not possible to generate 64 bit operations under Windows, including bit level .., .|. a.s.o. (from Data.Bits), and this situation will stay like this for a while. I'm asking this because I'm currently writing a pure Haskell chess engine based on bitboards. The bitboards are 64 bit wide and the basic operations are critical for speed, which is always critical in chess engines. Then it looks I'll have to implement these operations in C and use FFI to link them. Nicu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe use advice
Thanks Maciej! An additional Just was required in the refactored version of f: f (Rotatex : Rotatex': cs) = Just $ g (Rotate (x+x') : g cs) This is much cleaner than what I was doing. On Tue, Jun 7, 2011 at 4:14 AM, Maciej Piechotka uzytkown...@gmail.com wrote: On Tue, 2011-06-07 at 04:09 +0800, Lyndon Maydwell wrote: (missed including cafe) f :: [Modification] - Maybe [Modification] and f _ = Just $ f ... are incompatible My bad: f ... = let cs' = (Rotate (x+x') : fromMaybe cs (f cs)) in fromMaybe cs (f cs) Or refactoring it: g l = fromMaybe l (f l) f (Rotate x : Rotate x' : cs) = g (Rotate (x+x') : g cs) Regards I managed to get the behaviour I'm after with the use of Either, but this really is messy: -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = g (f (Left l)) where g (Right l) = Just $ Modifier (Changes l) i g (Left l) = Nothing f (Left (Scale x y : Scale x' y' : l)) = f $ Right $ Scale (x*x') (y*y') : h (f $ Left l) f (Left (Translate x y : Translate x' y' : l)) = f $ Right $ Translate (x+x') (y+y') : h (f $ Left l) f (Left (Rotate x : Rotate x' : l)) = f $ Right $ Rotate (x+x') : h (f $ Left l) f x = x h (Left l) = l h (Right l) = l On Tue, Jun 7, 2011 at 3:11 AM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: On Mon, 2011-06-06 at 23:38 +0800, Lyndon Maydwell wrote: I'm writing an optimisation routine using Uniplate. Unfortunately, a sub-function I'm writing is getting caught in an infinite loop because it doesn't return Nothing when there are no optimisations left. I'd like a way to move the last Just into f, but this makes recursion very messy. I was wondering if there was a nice way to use something like the Monad or Applicative instance to help here. -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = Just $ Modifier (Changes (f l)) i where f (Scale x y : Scale x' y' : l) = f $ Scale (x*x') (y*y') : f l f (Translate x y : Translate x' y' : l) = f $ Translate (x+x') (y+y') : f l f (Rotate x : Rotate x' : l) = f $ Rotate (x+x') : f l f l = l Any ideas? Something like: ... f (Rotate x : Rotate x' : l) = Just $ f (Rotate (x+x') : fromMaybe l (f l)) f l = Nothing -- As far as I understend Regards ___ 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] haskellwiki slow/unresponsive
Those are definitely valid concerns. Has anyone made a wiki-like site with Yesod? I hadn't heard of Yesod until I joined this mailing list, but I've seen quite a bit of buzz around it since then. If a large enough chunk of the community is backing a framework and focusing on making it secure and reliable, then it should be possible to build applications with it (wikis, blogs, etc.) that draw on the framework's strength and security. You may still have security issues, but if they're continually addressed and maintained at the framework level it benefits everyone building applications on top of that framework. I'm still relatively new to the Haskell community so I apologize if much of this has been addressed before! It is dead-simple to deploy a fast haskell web app, so haskell *might* have a chance at solving the problem, but likely it can be fixed much faster by doing a better job configuring the server or adding more resources. I think that security issues are a bit of a red herring. You can go through potential security issues one-by-one and basically make them impossible in a web/wiki framework (as we are doing in Yesod). Of course this is easier to do with a type system in Haskell. And of course some security is outside the scope of the software and needs to be established by procedure (admin server access should only be through ssh key, etc). Gitit uses darcs or git to store data, but through the command line interfaces. Unfortunately to my knowledge darcs does not expose a library interface. Gitit could be made faster and more secure by interfacing with libgit2. Even though it is may not be socially acceptable to state it, it is likely that gitit or any haskell library would be more secure in practice because it is more obscure. And the kind of security we really care about in the wiki- the wiki page content- can be easily replicated and restored. I definitely agree that the hard and boring part of switching to a haskell wiki is converting existing MediaWiki content and configuration to a new system- that would have to be investigated first. Unfortunately this is probably all bike-shedding and my original question of how can the community speed up the wiki hasn't been answered :) Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe use advice
Hi Lyndon Are you just coalescing adjacent elements (if they are the same constructor)? As it seems you have a list here rather than a tree, I'd step out of Uniplate at this point and just do a list traversal with direct recursion. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can it be proven there are no intermediate useful type classes between Applicative Functors Monads?
On Mon, Jun 6, 2011 at 3:39 PM, Casey McCann syntaxgli...@gmail.com wrote: On Mon, Jun 6, 2011 at 12:19 PM, Brent Yorgey byor...@seas.upenn.edu wrote: The idea is that Applicative computations have a fixed structure which is independent of intermediate results; Monad computations correspond to (potentially) infinitely branching trees, since intermediate results (which could be of an infinite-sized type) can be used to compute the next action; but Branching computations correspond to *finitely* branching trees, since future computation can depend on intermediate results, but only one binary choice at a time. Is this truly an intermediate variety of structure, though? Or just different operations on existing structures? With Applicative, there are examples of useful structures that truly can't work as a Monad, the usual example being arbitrary lists with liftA2 (,) giving zip, not the cartesian product. Do you know any examples of both: 1) Something with a viable instance for Branching, but either no Monad instance, or multiple distinct Monad instances compatible with the Branching instance I think Branching is to Monad what ArrowChoice is to ArrowApply. Branching allows the shape of the computation to depend on run-time values (which you can't do with Applicative), but still allows only a finite number of computation paths. By purposely making a functor an instance of Branching but _not_ of Monad, you allow it to have some amount of run-time flexibility while still retaining the ability to statically analyze the effects of a computation in that functor. branchApplicative = liftA3 (\b t f - if b then t else f) This definition doesn't satisfy the laws given for the Branching class; it will execute the effects of both branches regardless of which is chosen. Cheers, -Matt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Regression moving to ghc7
I'm trying to write a rolling window variation of the adler32 hash function (here: https://gist.github.com/1011151), and I got it to a nearly acceptable speed under ghc 6.12.3 (~35MB/s on my work machine), so I thought I'd see how the new ghc 7.0.3 treated it. The answer is not good. I get about 270KB/s. The key difference that I'm seeing from looking at the ghc-core program is that ghc 7.0.3 isn't using primitive ops for anything (unless they are no longer annotated with #). Can anybody shed any light as to what's going on? I'd also welcome any optimization tips that people would like to share. I've been messing with the code so much over the past day or two that I'm not even sure if it computes an adler32 anymore, but I hope that any optimization tops that pertain to that code would also apply to a correct algorithm. Right now, I'd just like to have the code run quickly, and to figure out why I'm seeing such a terrible regression under ghc7. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskellwiki slow/unresponsive
On Mon, Jun 6, 2011 at 4:45 PM, Greg Weber g...@gregweber.info wrote: Gitit uses darcs or git to store data, but through the command line interfaces. Unfortunately to my knowledge darcs does not expose a library interface. Gitit could be made faster and more secure by interfacing with libgit2. Darcs does export a library and pretty much has ever since I first cabalized it; see http://hackage.haskell.org/package/darcs for the module listings. It's not a very useful API, however. I don't know how to use it, and John doesn't know how to use libgit2, I suspect. -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Regression moving to ghc7
Right now, I'd just like to have the code run quickly, and to figure out why I'm seeing such a terrible regression under ghc7. From the #haskell channel, it looks like the horrible speed issue on this code is specific to my system. I'm re-building ghc7 now (bootstrapping ghc7 with ghc7 instead of ghc6), so maybe that will make something happier. If it doesn't, how does one go about figuring out why a program isn't being compiled to use primitive operations? just running ghc -v5 gives me so much information that I can't make any sense of it. Is there a less shotgun-like approach to seeing where the compiler is getting confused? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can it be proven there are no intermediate useful type classes between Applicative Functors Monads?
On Mon, Jun 6, 2011 at 5:32 PM, Matthew Steele mdste...@alum.mit.edu wrote: I think Branching is to Monad what ArrowChoice is to ArrowApply. Branching allows the shape of the computation to depend on run-time values (which you can't do with Applicative), but still allows only a finite number of computation paths. By purposely making a functor an instance of Branching but _not_ of Monad, you allow it to have some amount of run-time flexibility while still retaining the ability to statically analyze the effects of a computation in that functor. Yes, that's what I gathered as well. It's a straightforward concept. My question is whether there exist instances of Branching that are distinct in results from an implementation in terms of a Monad instance, rather than merely allowing a more efficient implementation. Not that the latter isn't worthwhile, but to make a case for something like Branching as an intermediate between Applicative and Monad one would expect it to differ from both in what types have possible instances. ArrowChoice and ArrowApply are conceptually distinct and I expect there are instances of the former that have no possible instance for the latter. Branching vs. Monad I am much less certain of. branchApplicative = liftA3 (\b t f - if b then t else f) This definition doesn't satisfy the laws given for the Branching class; it will execute the effects of both branches regardless of which is chosen. How would it violate the laws for Identity or Reader? - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Regression moving to ghc7
From the #haskell channel, it looks like the horrible speed issue on this code is specific to my system. I'm re-building ghc7 now (bootstrapping ghc7 with ghc7 instead of ghc6), so maybe that will make something happier. FWIW, rebuilding ghc7 using ghc7 as the bootstrapping implementation (and disabling the ghcquickbuild option, whatever that does) did give me a sane ghc7 that is giving the expected speeds. So, if anybody feels like pointing fingers at anything I could be doing better in my program, that's definitely welcome, but the regression part of my problem is gone. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Regression moving to ghc7
On 7 June 2011 10:12, tsuraan tsur...@gmail.com wrote: From the #haskell channel, it looks like the horrible speed issue on this code is specific to my system. I'm re-building ghc7 now (bootstrapping ghc7 with ghc7 instead of ghc6), so maybe that will make something happier. FWIW, rebuilding ghc7 using ghc7 as the bootstrapping implementation (and disabling the ghcquickbuild option, whatever that does) did give me a sane ghc7 that is giving the expected speeds. So, if anybody feels like pointing fingers at anything I could be doing better in my program, that's definitely welcome, but the regression part of my problem is gone. Oh, you built with ghcquickbuild? I don't remember the details, but if memory serves it disables a lot of optimisations, etc. just to get GHC built quicker to test that it compiles. So you probably don't want that ;-) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
On Mon, Jun 6, 2011 at 4:49 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: On 6/06/2011, at 8:11 AM, Chris Smith wrote: That's interesting... whatever the reason, though, I concur that using Note that the price for XCode applies to *XCode*. It's not a price for *GCC*. Having XCode, I was about to download GCC 4.5, build it, and install it in my own ~/local directory. Presumably, having built it, I could have copied it somewhere else. Correction: about should have been able. I don't actually use XCode on the laptop, just the gcc 4.5 I built from sources and the clang ditto. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On Mon, Jun 6, 2011 at 1:34 PM, Nicu Ionita nicu.ion...@acons.at wrote: Am 23.05.2011 13:32, schrieb Simon Marlow: On 18/05/2011 19:22, Jason Dagit wrote: On Wed, May 18, 2011 at 2:50 AM, John Sneerjohnsn...@operamail.com wrote: Hello all, I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed how to where is described building of Haskell Platform natively to 64bit Windows? If you figure out how to do this, I would like to know as well. I could also benefit from 64bit Haskell on windows. There is no port of GHC to 64-bit Windows yet. Various people have expressed an interest in having one, but it is a significant chunk of work to implement (plus extra work to maintain and build distributions), so we don't have any plans to do it in the short term. You can track progress (or lack thereof) by adding your email to the CC on the ticket: http://hackage.haskell.org/trac/ghc/ticket/1884 If you want to help out, join cvs-...@haskell.org and we can help with pointers to what needs to be done. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Hi, Just to double check: that means, today it's not possible to generate 64 bit operations under Windows, including bit level .., .|. a.s.o. (from Data.Bits), and this situation will stay like this for a while. Seems to work okay for me on windows: Prelude Data.Word Data.Bits (1 :: Word64) `shiftL` 62 4611686018427387904 Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Regression moving to ghc7
Oh, you built with ghcquickbuild? I don't remember the details, but if memory serves it disables a lot of optimisations, etc. just to get GHC built quicker to test that it compiles. So you probably don't want that ;-) That's good to know. It's too bad there doesn't seem to be a warning in the -v output that says all optimization is disabled or something, but now I know :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
I got asked a question today about why Control.Applicative is labeled as experimental on Hackage. Perhaps that field is something of a failed experiment, and it remaining there is likely to confuse people. Just a thought... not sure of the best place to mention it. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
On 6/6/11 1:52 AM, Yitzchak Gale wrote: You almost never want to use UndecidableInstances when writing practical programs in Haskell. When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP. That's a bit unfair. There are many kinds of type-level hackery which require UndecidableInstances but are (a) perfectly safe for practical use, and (b) have nothing to do with OOP. One particularly trivial example that comes to mind is: newtype Mu f = Mu (f (Mu f)) instance Show (f (Mu f)) = Show (Mu f) where show (Mu x) = Mu ( ++ show x ++ ) -- Or however you'd like to show it This can be solved for any f=F by, instance Show a = Show (F a) where... -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
