Re: [Haskell-cafe] holumbus error message -- unexpected package db stack
Ok, figured it out, based on your link, Jonathan, I thought of just running: make clean ./Setup configure ./Setup build ./Setup install WHICH of course imports Distribution.Simple, whereas calling make blah on the Makefile will not do the import of Distribution.Simple I'm glad the link helped. The error message you're seeing is actually in several places in the source. In the case where I've encountered this message, it's generated at the point where the Setup program is about to be compiled by cabal-install for a package with Build-Type: Custom; in this case, extra arguments were passed to cabal to set the GHC package database location, but those arguments failed a sanity check and resulted in the error message you saw. However, if you compile the Setup program by hand and bypass the check, you can still run it with whatever arguments you want and you won't see the error. The workaround I've used is to run cabal configure without the extra arguments. This will build the Setup program and then the Setup program can be run with whatever package-database-related arguments caused the error originally. So you may find that you see the error only when there is no preexisting dist/setup/setup program. But, again, I'd want to see how cabal is being invoked by the Makefile. -- Jonathan Daugherty ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
On 9/3/10 12:16 AM, Ivan Lazar Miljenovic wrote: 1) How should I name the kind * versions? For example, the kind * version of Functor is currently called Mappable with a class method of rigidMap. What should I call the kind * version of Foldable and its corresponding methods? Is there a valid system I can use for these? I think it'd be good to be consistent, whatever you do. For (*-*-*) monads I've seen them called GMonads (for generalized) and indexed monads. For the (*-*) monads, I've seen RMonads and parameterized monads. Here are some links for those who may be interested; they have more links to independent invention by Oleg Kiselyov and also by Bob Atkey, as well as a Coq implementation and a mention of Agda. (For my part, I've since moved on to playing with monads between different categories, which isn't really germane here.) http://winterkoninkje.dreamwidth.org/65416.html http://winterkoninkje.dreamwidth.org/65585.html So, in the interest of generality, perhaps you should just pick a letter or a short prefix and use that for each of the classes. In my blog posts I called them 0-monads, 1-monads, and 2-monads; following Ganesh Sittampalam and Matthieu Sozeau, they'd be monads, r-monads, and g-monads. 2) How far should I go? Should I restrict myself to the data-oriented classes such as Functor, Traversable, etc. or should I try to make restricted versions of Applicative and Monad? Assuming I should: I'd say you should do as much as seems reasonable. I tend to take things as far as I can, but that'd end up doing a lot of the same work as category-extras. For a general collections library, I think it'd make sense to try to keep things simpler than that if possible. The simpler it is, the better the uptake will be, so long as it's still complex enough to capture what it needs to. I'd say you should include: Functor, Foldable, Traversable, Pointed, Applicative, Monad, and Monoid (both additive and multiplicative in separate classes, as in the monoids package). Those eight make for a really comprehensive toolkit that does most of the things people frequently need. Of course, not every collection will have instances for all of them. (N.B., following the naming convention in those blog posts, 2-monoids are exactly the same as categories.) 2b) Is it OK to promote functions that use a class to being class methods? When I was discussing this in #haskell several people mentioned that defining something like liftA2 for the Set instance of (restricted) Applicative would make more sense than the default* (since (a - b) isnt' an instance of Ord). That depends. In general, it's better to have smaller classes because it reduces the burden on programmers writing instances and it allows for smaller dictionaries at runtime. In general, I'd say that functions should be included into the class when they often permit specialized definitions which are more efficient than the generic one. And of course, they should be included when they serve as the basis of the class (e.g., both (==) and (/=) should be included in Eq since they both serve as a basis for equality, with no one being obviously easier to implement than the other). If there's little chance of a performance gain, then why would you want it in the class at all? For example, many types can implement fmap/($) more efficiently than by using the liftM/liftA implementations or the default implementation from Foldable. (Of course, fmap is also a basis for the class.) For applicatives, the (*) and (*) operators should be included in the class too. While they seem trivial, some parser combinator libraries can get major performance improvements by using non-generic definitions. There was a discussion about this a while back, I forget if it was here or on the libraries list. And I forget if (**) also had efficient implementations... For another example of the principle, while compare is a sufficient basis for defining Ord, we include (), (=), (), (=) because they can often be implemented more efficiently than by using compare. 2c) Should I keep the classes as-is, or should I explicitly put in the constraints mentioned in the Typeclassopedia (e.g. make Applicative an explicit superclass of Monad, and define return = pure for compatability reasons)? If so, should I bring over Pointed, etc. from category-extras to round out the set or just stick with classes that are already in base? If you're defining a new hierarchy, I'd say you should do it correctly, i.e. classFunctor where fmap class Functor = Pointed where unit -- or point class Pointed = Applicative where (*) ; (*) ; (*) class Applicative = Monad where (=) ; join There's no benefit to preserving the ill designs of the past. 3) Am I wasting my time with this? Not at all. Many people want a good containers API, and many people want a cleaned up version of the categorical
Re: [Haskell-cafe] Restricted type classes
On 4 September 2010 17:40, wren ng thornton w...@freegeek.org wrote: On 9/3/10 12:16 AM, Ivan Lazar Miljenovic wrote: 1) How should I name the kind * versions? For example, the kind * version of Functor is currently called Mappable with a class method of rigidMap. What should I call the kind * version of Foldable and its corresponding methods? Is there a valid system I can use for these? I think it'd be good to be consistent, whatever you do. For (*-*-*) monads I've seen them called GMonads (for generalized) and indexed monads. For the (*-*) monads, I've seen RMonads and parameterized monads. Here are some links for those who may be interested; they have more links to independent invention by Oleg Kiselyov and also by Bob Atkey, as well as a Coq implementation and a mention of Agda. (For my part, I've since moved on to playing with monads between different categories, which isn't really germane here.) http://winterkoninkje.dreamwidth.org/65416.html http://winterkoninkje.dreamwidth.org/65585.html So, in the interest of generality, perhaps you should just pick a letter or a short prefix and use that for each of the classes. In my blog posts I called them 0-monads, 1-monads, and 2-monads; following Ganesh Sittampalam and Matthieu Sozeau, they'd be monads, r-monads, and g-monads. I think I'd prefer to put the prefix on the kind * versions (though does a kind * version of something like Monad even make sense?). 2) How far should I go? Should I restrict myself to the data-oriented classes such as Functor, Traversable, etc. or should I try to make restricted versions of Applicative and Monad? Assuming I should: I'd say you should do as much as seems reasonable. I tend to take things as far as I can, but that'd end up doing a lot of the same work as category-extras. For a general collections library, I think it'd make sense to try to keep things simpler than that if possible. The simpler it is, the better the uptake will be, so long as it's still complex enough to capture what it needs to. I'd say you should include: Functor, Foldable, Traversable, Pointed, Applicative, Monad, and Monoid (both additive and multiplicative in separate classes, as in the monoids package). Those eight make for a really comprehensive toolkit that does most of the things people frequently need. Of course, not every collection will have instances for all of them. Monoid was probably just going to be re-exported from base, since it's already for kind * (and as such works with all types, and doens't need any parametricity). 2b) Is it OK to promote functions that use a class to being class methods? When I was discussing this in #haskell several people mentioned that defining something like liftA2 for the Set instance of (restricted) Applicative would make more sense than the default* (since (a - b) isnt' an instance of Ord). That depends. In general, it's better to have smaller classes because it reduces the burden on programmers writing instances and it allows for smaller dictionaries at runtime. In general, I'd say that functions should be included into the class when they often permit specialized definitions which are more efficient than the generic one. And of course, they should be included when they serve as the basis of the class (e.g., both (==) and (/=) should be included in Eq since they both serve as a basis for equality, with no one being obviously easier to implement than the other). If there's little chance of a performance gain, then why would you want it in the class at all? Well, the point was that liftA/liftA2 might make more sense as being the methods to be defined for some types rather than *, but you could define them in terms of each other. 2c) Should I keep the classes as-is, or should I explicitly put in the constraints mentioned in the Typeclassopedia (e.g. make Applicative an explicit superclass of Monad, and define return = pure for compatability reasons)? If so, should I bring over Pointed, etc. from category-extras to round out the set or just stick with classes that are already in base? If you're defining a new hierarchy, I'd say you should do it correctly, i.e. class Functor where fmap class Functor = Pointed where unit -- or point class Pointed = Applicative where (*) ; (*) ; (*) class Applicative = Monad where (=) ; join There's no benefit to preserving the ill designs of the past. Yes, that was my point. 3) Am I wasting my time with this? Not at all. Many people want a good containers API, and many people want a cleaned up version of the categorical classes which isn't quite as involved as category-extras. Go for it! *sigh* I was almost wishing people would say I _was_ wasting my time with this... ;-) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list
Re: [Haskell-cafe] Restricted type classes
On 9/4/10 3:50 AM, Ivan Lazar Miljenovic wrote:
On 4 September 2010 17:40, wren ng thorntonw...@freegeek.org wrote:
So, in the interest of generality, perhaps you should just pick a letter or
a short prefix and use that for each of the classes. In my blog posts I
called them 0-monads, 1-monads, and 2-monads; following Ganesh Sittampalam
and Matthieu Sozeau, they'd be monads, r-monads, and g-monads.
I think I'd prefer to put the prefix on the kind * versions (though
does a kind * version of something like Monad even make sense?).
Oh sure. I was just meaning that you should do something systematic like
have XFoo and YFoo, instead of having Foo and Bar. That way people can
just remember ({X,Y},{Foo,Fob,Fez}) instead of having to remember
{(Foo,Bar), (Fob,Baz), (Fez,Quux)}.
I'm a fan of keeping the undecorated names for the current versions, and
using a prefix for the * versions.
I'd say you should include: Functor, Foldable, Traversable, Pointed,
Applicative, Monad, and Monoid (both additive and multiplicative in separate
classes, as in the monoids package). Those eight make for a really
comprehensive toolkit that does most of the things people frequently need.
Of course, not every collection will have instances for all of them.
Monoid was probably just going to be re-exported from base, since it's
already for kind * (and as such works with all types, and doens't need
any parametricity).
I was just talking general API, not necessarily what you need to write.
Reusing the standard classes is fine.
Well, the point was that liftA/liftA2 might make more sense as being
the methods to be defined for some types rather than*, but you
could define them in terms of each other.
Well, liftA and liftM are just generic implementations of fmap using
pure/(*) and return/(=). If you can define fmap directly, then you
should do so. If you can't, you're always free to use the
implementations that liftA and liftM use. The liftA function is defined
explicitly for allowing you can say instance Functor F where fmap =
liftA. There's no reason for liftA to belong to Applicative, because
it has Functor as a superclass and therefore fmap exists. Since fmap can
be more efficient than liftA, it is better to use fmap when writing
code. Note that ($) is defined as fmap, and liftA2, liftA3, etc are
defined in terms of ($) i.e. fmap.
For liftM things are a bit hazier because Monad fails to mention Functor
as an explicit superclass, but it really ought to. Assuming it did, then
there's no reason for liftM to belong to Monad, because we're assured
that fmap exists. Though, again, liftM should be defined as a non-class
function in order to serve as a default implementation of fmap for those
who need it. This is the same reason why Data.Traversable defines
fmapDefault and foldMapDefault: not so that they can be used as
functions, but so that they can be used for giving class instances.
Perhaps we should be calling them fmapApplictiveDefault,
fmapMonadDefault, and fmapTraversableDefault instead...
I suppose you could use liftA2 as the basis of Applicative instead of
(*), but that seems a bit perverse to me. The (*) operation captures
exactly what we want to say--- namely the K axiom for modal logics;
which is equivalent to saying the applicative category has exponentials;
which is also the name for the whitespace of function application;... .
Whereas liftA2 seems like a far more round-about way of getting there.
There may be efficiency reasons for arguing that liftA2 should be
included in _addition_ to (*), but I'm not aware of them.
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
On 4 September 2010 18:27, wren ng thornton w...@freegeek.org wrote:
On 9/4/10 3:50 AM, Ivan Lazar Miljenovic wrote:
On 4 September 2010 17:40, wren ng thorntonw...@freegeek.org wrote:
So, in the interest of generality, perhaps you should just pick a letter
or
a short prefix and use that for each of the classes. In my blog posts I
called them 0-monads, 1-monads, and 2-monads; following Ganesh
Sittampalam
and Matthieu Sozeau, they'd be monads, r-monads, and g-monads.
I think I'd prefer to put the prefix on the kind * versions (though
does a kind * version of something like Monad even make sense?).
Oh sure. I was just meaning that you should do something systematic like
have XFoo and YFoo, instead of having Foo and Bar. That way people can just
remember ({X,Y},{Foo,Fob,Fez}) instead of having to remember {(Foo,Bar),
(Fob,Baz), (Fez,Quux)}.
I'm a fan of keeping the undecorated names for the current versions, and
using a prefix for the * versions.
Right, so what prefix? ;-)
Well, liftA and liftM are just generic implementations of fmap using
pure/(*) and return/(=). If you can define fmap directly, then you
should do so. If you can't, you're always free to use the implementations
that liftA and liftM use. The liftA function is defined explicitly for
allowing you can say instance Functor F where fmap = liftA. There's no
reason for liftA to belong to Applicative, because it has Functor as a
superclass and therefore fmap exists. Since fmap can be more efficient than
liftA, it is better to use fmap when writing code. Note that ($) is
defined as fmap, and liftA2, liftA3, etc are defined in terms of ($) i.e.
fmap.
Gah, you're right. I didn't think that liftA = fmap.
For liftM things are a bit hazier because Monad fails to mention Functor as
an explicit superclass, but it really ought to. Assuming it did, then
there's no reason for liftM to belong to Monad, because we're assured that
fmap exists. Though, again, liftM should be defined as a non-class function
in order to serve as a default implementation of fmap for those who need it.
Hmmm, I was thinking of just having liftM = fmap, but yeah using the
monadic defaults makes sense to avoid having to define fmap
explicitly.
This is the same reason why Data.Traversable defines fmapDefault and
foldMapDefault: not so that they can be used as functions, but so that they
can be used for giving class instances. Perhaps we should be calling them
fmapApplictiveDefault, fmapMonadDefault, and fmapTraversableDefault
instead...
I suppose you could use liftA2 as the basis of Applicative instead of (*),
but that seems a bit perverse to me. The (*) operation captures exactly
what we want to say--- namely the K axiom for modal logics; which is
equivalent to saying the applicative category has exponentials; which is
also the name for the whitespace of function application;... . Whereas
liftA2 seems like a far more round-about way of getting there. There may be
efficiency reasons for arguing that liftA2 should be included in _addition_
to (*), but I'm not aware of them.
Well, I _can_ define * for Sets (and have done so), but such an
instance doesn't make any sense because functions don't have Ord
instances. As such, the default liftA2, etc. definitions don't work
with Sets because of this.
--
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] New .hs File Icons
This looks great! On Fri, Sep 3, 2010 at 4:59 PM, Christian Eltges elt...@googlemail.com wrote: Hello, I was wondering why the File-Icon installed by GHC with the lambda for .hs files hasn't changed to the new bind+lambda icon used on haskel.org. Is this because it should be the same as the icon used by hugs? I've created a new icon myself, which I use on my pc (using the svg file from the haskell wiki). So if the only reason for using the old icon was, that there is no new one, then you can use this. Best regards Christian ___ 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] Restricted type classes
On 4 September 2010 08:50, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: 3) Am I wasting my time with this? Not at all. Many people want a good containers API, and many people want a cleaned up version of the categorical classes which isn't quite as involved as category-extras. Go for it! *sigh* I was almost wishing people would say I _was_ wasting my time with this... ;-) Hi Ivan Okay, I'll bite... Its good someone is looking into arity versions of Monad, Applicative etc. I think previously pointed you to Conor McBride's message on the subject: http://www.haskell.org/pipermail/haskell-cafe/2008-June/044011.html But, I don't know that work on this will lead to a better API for collection classes... Supposing classes is the way to go, I think there's still a lot of design work to be done on what the classes should be rather than how they are implemented. The current design space (ListLike and your Data.Containers) looks like a factoring of the operations from Data.List and Data.Sequence, personally I have serious doubts that this will lead to a nice API. If I was looking at it myself, I'd start from Chris Okasaki and Ralf Hinze's observations that data structures have analogies to numerical representations. So, I would try to build classes upwards from that (monoid is obviously already in place), rather than design by factoring what List already has. As an example, I think someone has pointed out on the Cafe that C++ has a container library following the analogy to numerical representations. As an aside I thought someone added an implementation of Simon Peyton Jones's Bulk Types with Class to Hackage recently? If they did they didn't give it a findable description. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
On 4 September 2010 18:54, Stephen Tetley stephen.tet...@gmail.com wrote: Supposing classes is the way to go, I think there's still a lot of design work to be done on what the classes should be rather than how they are implemented. The current design space (ListLike and your Data.Containers) looks like a factoring of the operations from Data.List and Data.Sequence, personally I have serious doubts that this will lead to a nice API. If I was looking at it myself, I'd start from Chris Okasaki and Ralf Hinze's observations that data structures have analogies to numerical representations. So, I would try to build classes upwards from that (monoid is obviously already in place), rather than design by factoring what List already has. As an example, I think someone has pointed out on the Cafe that C++ has a container library following the analogy to numerical representations. Where exactly can I find these observations on the analogies between data structures and numerical representations? -- 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] Haddock: Documentation of instances with un-documentable type arguments
Hi Is there a similar ticket for GHC to not export instances in the case that other instances are explicitly specified? module Foo ( Foo(Monad) ) instance Monad Foo where ... instance MonadState (Foo Bar) where ... i.e. the monad instance gets exported but the MonadState one does not? This helps in maintaining opacity with respect to the package user. I may not want the user to be able to call 'get' and 'put' when using my custom monad. Cheers, Vivian On 26 August 2010 02:20, David Waern david.wa...@gmail.com wrote: 2010/8/25 Alexander McPhail haskell.vivian.mcph...@gmail.com: Perhaps Haddock could exclude class instance reporting when it cannot find a documentable link to a parameter? Yes, it should. BTW, we have a trac ticket for it: http://trac.haskell.org/haddock/ticket/37 You can add yourself to the CC list to show that you want this feature. Currently we don't have many people working on these types of tickets in Haddock (I'm mostly fixing bugs, others are working on bigger improvements), so if more people would volunteer to help out, that'd be great. The mailing list hadd...@projects.haskell.org can be used to ask for directions and help. David -- --- yolar et elver. --- DISCLAIMER This transmission contains information that may be confidential. It is intended for the named addressee only. Unless you are the named addressee you may not copy or use it or disclose it to anyone else. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
On 4 September 2010 09:57, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Where exactly can I find these observations on the analogies between data structures and numerical representations? Chris Okasaki - Chapter 9 of Purely Functional Data Structures. Ralf Hinze's slides Number Systems and Data Structures, March 2005 - http://www.cs.nott.ac.uk/~gmh/bctcs-slides/hinze.pdf On second thoughts, I don't think C++ has a collection classes library designed in this way. The message on the Cafe I had in mind was this one, but it is talking about something else: http://www.haskell.org/pipermail/haskell-cafe/2010-April/076157.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TryHaskell in the classroom!
On 4 September 2010 02:02, Fritz Ruehr fru...@willamette.edu wrote: I just wanted to send out a more public Thanks! to Chris Done for the tryhaskell.org website and to everyone else (including Chris) who was on the #haskell channel of IRC this afternoon when I tried haskell, along with the chat feature, during my introductory functional programming class. Glad to hear it! This is an ideal scenario for Try Haskell! Thanks for using it! On 4 September 2010 02:11, Benjamin L. Russell dekudekup...@yahoo.com wrote: I have also enjoyed using Try Haskell. It would be wonderful if it could be expanded with more content. Many thanks to the developers for their efforts! Community contributed lessons are welcome! I'll be adding some hpaste integration too. A markdown format like the below should be sufficient: Title: Example Message: Here is a message about integers! Here are some numbers: 23^75 23/52 Enter a number like `23`. Title: Well done Type-Trigger: Num t = t Value-Trigger: 23 Message: Great, you typed %value% and it has type %type%. Etc. And so on. Until I write a tutorial composer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock: Documentation of instances with un-documentable type arguments
On 4 September 2010 19:01, Alexander McPhail haskell.vivian.mcph...@gmail.com wrote: Hi Is there a similar ticket for GHC to not export instances in the case that other instances are explicitly specified? module Foo ( Foo(Monad) ) instance Monad Foo where ... instance MonadState (Foo Bar) where ... i.e. the monad instance gets exported but the MonadState one does not? This helps in maintaining opacity with respect to the package user. I may not want the user to be able to call 'get' and 'put' when using my custom monad. No: instances are implicitly imported and exported (if the class and the type are visible, then so are any possible instances). -- 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
[Haskell-cafe] Haskell Platform on Windows - cabal update problems.
I've installed recent Haskell Platform and tried to wrap my head around cabal to finally figure out how to use it. First thing I bumped into is that cabal.exe does not know about any remote repositories, even about hackage. So after googling I found that I should add a line remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive; into my cabal config file. So I did. And now I have cabal update command trying to download packages list from hackage. To no avail. Now it gives me even more interesting error: cabal.EXE: fromFlag NoFlag. Use fromFlagOrDefault Googling doesn't help here. What does it mean and how to get rid of it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Crypto-API is stabilizing
On Sat, Sep 4, 2010 at 3:23 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: A better reason is the data structure has no way to implement generateKeyPair. That's a non-problem: each algorithm (RSA, DSA, ...) implements a function with the same type as generateKeyPair . Compare rsa :: RangomGen g = BitLength - g - ((Key,Key), g) vs ((k1 :: RSA, k2), g') = generateKeyPair g You always have to write down the name of the algorithm (RSA) when using generateKeyPair , so you may as well drop it entirely. That simply isn't true. What if you have a key exchange in which the ephemeral key is of the same type as your signing key? Slightly contrived example: buildAgreementMessage :: (Monad m, CryptoRandomGen g, ASymetricCipher k) = g - k - m (B.ByteString,g) buildAgreementMessages g k = do (e,g') - liftM eitherToFail (buildAsymKey g `asTypeOf` k) let eBS = encode e msg = runPut (putByteString agreementHeader putWord16be (B.length eBS) putByteString eBS) return msg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New .hs File Icons
GHC's icon is a little different from Hugs' icon. However, your icon is prettier. WinGHCi's icon is nice too. Off course, it's just an opinion. -- Daniel Díaz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Fri, Sep 3, 2010 at 23:02, David Menendez d...@zednenem.com wrote: Yes, using foreign namespaces is one of the things recommended against when serving XHTML as text/html. This says nothing about documents following the recommendations in Appendix C. I'm not debating that it's *possible* to serve HTML with an XHTML mimetype and still see something rendered to the screen. Hundreds of thousands of sites do so every day. But to call this XHTML is absurd. I agree, if by absurd you mean consistent with the letter and spirit of the XHTML recommendation. Content served as text/html is not XHTML, any more than content served as text/plain or image/jpg is. *IF* XHTML could be served using text/html, then my example pages would render identically in browsers with XHTML support. Appendix C is a guideline on how to make the same byte content render *something* when treated as HTML or XHTML; it's intended as a low-fidelity fallback for user agents without support for XHTML (IE). It is *not* a means by which HTML may be labelled XHTML for the sake of buzzword compliance. You seem to be under the common misconception that XHTML is merely an alternative encoding of HTML. This is incorrect. XHTML has a different DOM, different CSS support, and different syntax. HTML and XHTML are like Java and C# -- beneath a superficial resemblance, distinct. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Crypto-API is stabilizing
Sorry, the example was all messed up, even if it did communicate what I wanted its just so broken I must fix. Slightly contrived example: buildAgreementMessage :: (Monad m, CryptoRandomGen g, ASymetricCipher k) = g - k - m (B.ByteString, (k,k), g) buildAgreementMessages g k = do ((p,q),g') - eitherToFail (buildKeyPair g) let pBS = encode p msg = runPut $ do putByteString agreementHeader putWord16be (B.length pBS) putByteString pBS return $ (sign msg k, (p,q), g') Again, this is simply trying to re-enforce the fact that buildKeyPair (formerly 'generateKeyPair') does have a place. Cheers, Thomas On Sat, Sep 4, 2010 at 7:45 AM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: Slightly contrived example: buildAgreementMessage :: (Monad m, CryptoRandomGen g, ASymetricCipher k) = g - k - m (B.ByteString,g) buildAgreementMessages g k = do (e,g') - liftM eitherToFail (buildAsymKey g `asTypeOf` k) let eBS = encode e msg = runPut (putByteString agreementHeader putWord16be (B.length eBS) putByteString eBS) return msg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Laziness bug in Data.List.intersperse (was: ANNOUNCE: text 0.8.0.0, fast Unicode text support)
On Wed, Sep 1, 2010 at 1:00 PM, Daniel Fischer daniel.is.fisc...@web.dewrote: I'm not keen on subscribing to libraries@ to follow the official proposal process, any takers? I'll take it up. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] help me evangelize haskell.
I'll be starting a new job soon as systems tool guy. The shop is a perl shop as far as internal automation tasks go. But I am fortunate to not be working with bigots. If they see a better way, they'll take to it. So please give me your best arguments in favor of using haskell for task automation instead of perl, or awk or any of those scripting lanugages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
2010/9/4 Michael Litchard mich...@schmong.org: I'll be starting a new job soon as systems tool guy. The shop is a perl shop as far as internal automation tasks go. But I am fortunate to not be working with bigots. If they see a better way, they'll take to it. So please give me your best arguments in favor of using haskell for task automation instead of perl, or awk or any of those scripting lanugages. Hi, At a talk presented during a Ghent FPG meeting, someone explained how they brought Ocaml to the work place. Basically, they made a drop-in replacement for a C++ (or maybe was it C) library. Less code, same or above performance. Maybe they had also a good reason to rewrite the library (because it was too big, or too difficult to maintain), not just as a proof that Ocaml was better suited. I guess that in your case, Perl for internal automation task, you should find some little tool for which it would be acceptable to dedicate some time rewriting it in Haskell. Tell us how all this unfolds. Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Regular expressions on Windows 7
Hello - I am following the book Real World Haskell. I am looking at the chapter on regular expressions and trying examples on WinGHCi. However, it cannot load regex-posix-0.94.2 - apparently a file regex.h is missing. I think this has been known for some time. Are there plans to have working regexes on the Windows platform? I am not enough of a hacker to be able to understand material on the Web on this subject - the problem may have been solved somewhere. Regards _John Sampson_ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
I have only one thing to add to this discussion: On Fri, Sep 3, 2010 at 5:16 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: 2b) Is it OK to promote functions that use a class to being class methods? When I was discussing this in #haskell several people mentioned that defining something like liftA2 for the Set instance of (restricted) Applicative would make more sense than the default * (since (a - b) isnt' an instance of Ord). One problem with defining both * and liftA2 in the class in terms of each other is that omitting them from instances is no longer a compile-time error, nor is it even an obvious runtime error - it's frequently an infinite loop, which is unpleasant. Though I understand that it's nice to be able to choose the methods you want to define, I think static error detection is nice too, so I tend to avoid providing extra class methods with defaults unless the alternative is much worse. On that note, why *do* we have missing instance methods filled in with bottoms, so that even without defaults, it's a warning rather than an error? It seems like quite an un-Haskelly thing to do. I know there may be some cases where you do not need to define a particular method, but imo you should be required to explicitly opt out of it if that's the case. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Sat, Sep 4, 2010 at 11:07 AM, John Millikin jmilli...@gmail.com wrote: On Fri, Sep 3, 2010 at 23:02, David Menendez d...@zednenem.com wrote: Yes, using foreign namespaces is one of the things recommended against when serving XHTML as text/html. This says nothing about documents following the recommendations in Appendix C. I'm not debating that it's *possible* to serve HTML with an XHTML mimetype and still see something rendered to the screen. Hundreds of thousands of sites do so every day. But to call this XHTML is absurd. I agree, if by absurd you mean consistent with the letter and spirit of the XHTML recommendation. Content served as text/html is not XHTML, any more than content served as text/plain or image/jpg is. Metadata does not determine data. If I write created: 1810 on the Haskell Report, that does not make it 200 years old. If I seve a JPEG image as text/html, it's still a JPEG image. We just wouldn't expect a browser to render it correctly, because the metadata is wrong. Appendix C describes a subset of XHTML, such that a document in conformance with it may be interpreted usefully as HTML by most web browsers. The document is still XHTML, and may be given to XHTML or generic XML tools without difficulty. You seem to be under the common misconception that XHTML is merely an alternative encoding of HTML. HTML and XHTML are not encodings of anything. They are markup languages defined using SGML and the XML subset of SGML. There are multiple HTML definitions of varying popularity, and the fact that we can pass some XHTML documents to a web browser expecting HTML and get acceptable results is consistent with the fact that we can pass HTML 3.0 (never implemented by any popular browser) with minimal loss. -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
My usual rhetoric is that one-off, throwaway scripts never are, and not only do they tend to stay around but they take on a life of their own. Today's 10-line file munger is tomorrow's thousand-line ETL batch job on which the business depends for some crucial data - yet the original author is long gone and no-one dares modify in case it breaks. So it is just good sense to use sound practices from the very beginning. One of the features of Perl is that it will try to work even if you make type errors (e.g. give it a scalar in place of a list, or a string instead of an int). One day, however, it WILL fail. Haskell finds these types of bugs upfront, and not when your pager goes off at 3am... Cheers, G --Original Message-- From: Michael Litchard Sender: haskell-cafe-boun...@haskell.org To: haskell-cafe@haskell.org Subject: [Haskell-cafe] help me evangelize haskell. Sent: Sep 4, 2010 17:38 I'll be starting a new job soon as systems tool guy. The shop is a perl shop as far as internal automation tasks go. But I am fortunate to not be working with bigots. If they see a better way, they'll take to it. So please give me your best arguments in favor of using haskell for task automation instead of perl, or awk or any of those scripting lanugages. ___ 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] Restricted type classes
On Fri, Sep 3, 2010 at 8:23 AM, John Lato jwl...@gmail.com wrote: Do you have a kind * implementation of Foldable? I'd be interested in seeing it, because I was unable to create a usable implementation (based upon the RMonad scheme) on my last attempt. I always figured it would look something like: class Foldable f where type Elem f :: * foldMap :: Monoid m = (Elem f - m) - f - m with the usual definitions for foldr, foldl, etc. +1 for using the proper constraints, and especially for bringing over Pointed (and anything else that applies). What's the argument for Pointed? Are there many types which are instances of Pointed but not Applicative? Are there many algorithms which require Pointed but not Applicative? -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Regular expressions on Windows 7
I think version 0.94.4 has the regex.h file and works on Windows: http://hackage.haskell.org/package/regex-posix-0.94.4 On 04/09/2010 18:10, John Sampson wrote: Hello - I am following the book Real World Haskell. I am looking at the chapter on regular expressions and trying examples on WinGHCi. However, it cannot load regex-posix-0.94.2 - apparently a file regex.h is missing. I think this has been known for some time. Are there plans to have working regexes on the Windows platform? I am not enough of a hacker to be able to understand material on the Web on this subject - the problem may have been solved somewhere. Regards _John Sampson_ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] On to applicative
The two myAction functions below seem to be equivalent and, for this small case, show an interesting economy of code, but being far from a Haskell expert, I have to ask, is the first function as small (code wise) as it could be? Michael import Control.Applicative data Color = Red | Blue | Green | Yellow | Orange | Brown | Black | White deriving (Show, Read, Eq, Enum, Ord, Bounded) -- myAction :: IO Color -- myAction = getLine -- = \str - return (read str :: Color) myAction :: IO Color myAction = read $ getLine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On to applicative
On Sat, Sep 4, 2010 at 2:06 PM, michael rice nowg...@yahoo.com wrote: The two myAction functions below seem to be equivalent and, for this small case, show an interesting economy of code, but being far from a Haskell expert, I have to ask, is the first function as small (code wise) as it could be? Michael import Control.Applicative data Color = Red | Blue | Green | Yellow | Orange | Brown | Black | White deriving (Show, Read, Eq, Enum, Ord, Bounded) -- myAction :: IO Color -- myAction = getLine --= \str - return (read str :: Color) First, you don't need the type annotation here. Haskell will infer it from the annotation on myAction. (You also don't need the type on myAction, but that's not important now.) myAction = getLine = \str - return (read str) Second, you have the pattern \x - f (g x), so you can replace the lambda with function composition. myAction = getLine = return . read Third, there is a standard function liftM, defined in Control.Monad, where liftM f m = m = return . f, so myAction = liftM read getLine Finally, we expect an instance of Monad to also be an instance of Functor, with fmap = liftM, and we also have f $ m = fmap f m, so myAction :: IO Color myAction = read $ getLine -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On to applicative
Hi Dave, I wrote the first one sometime last year and it seemed a suitably simple example for applicative-izing to cement the ideas in some of the code I've been going though in Learn You a Haskell ... Interesting stuff. Onward and upward. Thanks, Michael --- On Sat, 9/4/10, David Menendez d...@zednenem.com wrote: From: David Menendez d...@zednenem.com Subject: Re: [Haskell-cafe] On to applicative To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org Date: Saturday, September 4, 2010, 2:23 PM On Sat, Sep 4, 2010 at 2:06 PM, michael rice nowg...@yahoo.com wrote: The two myAction functions below seem to be equivalent and, for this small case, show an interesting economy of code, but being far from a Haskell expert, I have to ask, is the first function as small (code wise) as it could be? Michael import Control.Applicative data Color = Red | Blue | Green | Yellow | Orange | Brown | Black | White deriving (Show, Read, Eq, Enum, Ord, Bounded) -- myAction :: IO Color -- myAction = getLine -- = \str - return (read str :: Color) First, you don't need the type annotation here. Haskell will infer it from the annotation on myAction. (You also don't need the type on myAction, but that's not important now.) myAction = getLine = \str - return (read str) Second, you have the pattern \x - f (g x), so you can replace the lambda with function composition. myAction = getLine = return . read Third, there is a standard function liftM, defined in Control.Monad, where liftM f m = m = return . f, so myAction = liftM read getLine Finally, we expect an instance of Monad to also be an instance of Functor, with fmap = liftM, and we also have f $ m = fmap f m, so myAction :: IO Color myAction = read $ getLine -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Sat, Sep 4, 2010 at 12:19 PM, David Menendez d...@zednenem.com wrote: HTML and XHTML are not encodings of anything. They are markup languages defined using SGML and the XML subset of SGML. There are multiple HTML definitions of varying popularity, and the fact that we can pass some XHTML documents to a web browser expecting HTML and get acceptable results is consistent with the fact that we can pass HTML 3.0 (never implemented by any popular browser) with minimal loss. But what is the point? The w3c originally suggested serving xhtml as text/html back in 2000 (http://www.w3.org/2000/01/xhtml-pressrelease.html.en), because they believed that it would be an easy way for people to transition to xhtml while the browsers caught up. Well, a decade later, ie still doesn't support xhtml, so perhaps their recommendation should be viewed in light of the fact that the web does not appear to be moving to xhtml at any great speed. Creating output that renders the same as both text/html and application/xml is not a trivial task. For starters, the contents of the script tag are treated as pcdata in html, and cdata in xhtml. And it only gets worse from there... So the choices are: 1. only focus on getting the xhtml 1.0 served as application/xml working correctly, and ie users get nothing.. 2. create xhtml 1.0 that would work correctly if served as application/xml, but serve it as text/html, and ignore that fact that some stuff might not be rendering correctly when treated as text/html. 3. create xhtml documents which render correctly whether served as application/xml or text/html, but then only serve them as text/html anyway 4. forget about how the xhtml documents render as application/xml, and only focus on how they render as text/html. Now, I think that options 1 and 2 are not even worth considering. Option 4 seems silly. If you are going to create xhtml that does not really work correctly when actually served as xhtml, then why create xhtml in the first place. This is really just html masquerading as xhtml. Why not actually create valid html and serve it as text/html, instead of creating purposely broken html? Option 3 requires extra work (and also means that you will never be able to upgrade to xhtml 1.1 or xhtml 2.0). The idea of serving xhtml 1.0 as text/html was supposed to be a transitional measure. But if you intend to do it forever.. that is not very transitional. What benefit do you get by creating xhtml 1.0 that also happens to render correctly as html ? What is the use case ? Seems that a vast majority of the usage is going to be viewing the content in web browsers. For that purpose, text/html seems superior, due to it being supported in a much wider variety of browsers. No browser will actually even try to render it as xhtml since it is being served as text/html. It seems that the only advantage of xhtml served as text/html is that it is easier to process the output. But, is anyone actually going to do that? Haddock has been around for a long time.. has anyone had a need to do that so far? And even then, is processing it via an xml parser really better than using tagsoup ? Mark suggested that it was easier to achieve multi-browser compatibility using xhtml instead of html, but I am quite certain he is mistaken. There are really three different rendering modes found in browsers: 1. standards mode 2. quirks mode 3. xhtml mode By serving xhtml content as text/html, he is getting browsers to use quirks mode instead of standards mode. That *can* sometimes lead to better browser compatibility. He is never invoking the xhtml rendering mode. If the aim is simply to trigger quirks mode, there is no need to use xhtml to achieve that. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell Platform on Windows - cabal update problems.
Hi, Serguey Zefirov sergueyz at gmail.com writes: I've installed recent Haskell Platform and tried to wrap my head around cabal to finally figure out how to use it. [...] Now it gives me even more interesting error: cabal.EXE: fromFlag NoFlag. Use fromFlagOrDefault Googling doesn't help here. What does it mean and how to get rid of it? Try removing the 'Application Data/cabal' directory and running 'cabal update'. You probably made a syntax error in the config file. Here's a log of what I do after a clean HP install: E:\cabal no command given (try --help) E:\cabal install pointfree Config file path source is default config file. Config file Application Data\cabal\config not found. Writing default configuration to Application Data\cabal\config Warning: The package list for 'hackage.haskell.org' does not exist. Run 'cabal update' to download it. cabal: There is no package named pointfree. Perhaps you need to run 'cabal update' first? E:\cabal update Downloading the latest package list from hackage.haskell.org E:\cabal install pointfree Resolving dependencies... Downloading pointfree-1.0.3... Configuring pointfree-1.0.3... Preprocessing executables for pointfree-1.0.3... Building pointfree-1.0.3... [1 of 7] Compiling Plugin.Pl.Common ( Plugin\Pl\Common.hs, dist\build\pointfree\ pointfree-tmp\Plugin\Pl\Common.o ) [2 of 7] Compiling Plugin.Pl.Parser ( Plugin\Pl\Parser.hs, dist\build\pointfree\ pointfree-tmp\Plugin\Pl\Parser.o ) [3 of 7] Compiling Plugin.Pl.PrettyPrinter ( Plugin\Pl\PrettyPrinter.hs, dist\bu ild\pointfree\pointfree-tmp\Plugin\Pl\PrettyPrinter.o ) [4 of 7] Compiling Plugin.Pl.Transform ( Plugin\Pl\Transform.hs, dist\build\poin tfree\pointfree-tmp\Plugin\Pl\Transform.o ) [5 of 7] Compiling Plugin.Pl.Rules ( Plugin\Pl\Rules.hs, dist\build\pointfree\p ointfree-tmp\Plugin\Pl\Rules.o ) [6 of 7] Compiling Plugin.Pl.Optimize ( Plugin\Pl\Optimize.hs, dist\build\pointf ree\pointfree-tmp\Plugin\Pl\Optimize.o ) Linking dist\build\pointfree\pointfree.exe ... Installing executable(s) in E:\\Application Data\cabal\bin E:\pointfree 1 + 2 3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New .hs File Icons
Christian Eltges eltges at googlemail.com writes: Hello, I was wondering why the File-Icon installed by GHC with the lambda for .hs files hasn't changed to the new [...] So if the only reason for using the old icon was, that there is no new one, then you can use this. Cool, thanks! I'll include this in the next Haskell Platform installer. It'd be also nice to have separate icons for .lhs files - a differently colored lambda perhaps? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Platform on Windows - cabal update problems.
2010/9/5 Mikhail Glushenkov the.dead.shall.r...@gmail.com: Try removing the 'Application Data/cabal' directory and running 'cabal update'. You probably made a syntax error in the config file. You are clearly a magician. ;) Now it works flawlessly. Thank you very much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does ghci recompile the module compiled in different OS ?
Are you trying to use the .o compiled on BSD on Linux? They are two different operating systems. So the Linux ghci isn't using the .o, it's using the .hs. Even getting Haskell binaries to run on two different versions of Linux can be an adventure... http://gaiustech.wordpress.com/2010/09/03/on-deployment/ Cheers, G On 4 Sep 2010, at 02:36, zaxis wrote: Both linux and freebsd has the same .ghci file. cat ~/.ghci :def hoogle \str - return $ :! hoogle --count=15 \ ++ str ++ \ :cd /media/G/www/qachina/db/doc/money the money.hs has many functions i need to use. On freebsd, i use the following command to compile it: ghc -c -O2 money.hs ls Money.hi Money.hs Money.o When entering ghci, it indeed doesnot recompile the module. ghci ... Ok, modules loaded: Money However, when i use the same module in archlinux, the ghci does recompile the module: ghci ... [1 of 1] Compiling Money( Money.hs, interpreted ) Ok, modules loaded: Money. Any suggestion is appreciated! - e^(π⋅i) + 1 = 0 -- View this message in context: http://old.nabble.com/Why-does-ghci-recompile-the-module-compiled-in-different-OS---tp29619740p29619740.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On 10-09-04 01:31 AM, John Millikin wrote: It's not correct. Here's the exact same XHTML document (verify by viewing the source), served with different mimetypes: http://ianen.org/temp/inline-svg.html http://ianen.org/temp/inline-svg.xhtml This relies on xhtml+svg. While it is in the xhtml family, it is not xhtml 1.0 (Section 3.1.2). This is a non-example and non-reason. New haddock pages are xhtml 1.0 (after repairing IDs). I'm not debating that it's *possible* to serve HTML with an XHTML mimetype and still see something rendered to the screen. Hundreds of thousands of sites do so every day. But to call this XHTML is absurd. You have got the order reversed. serve html with an xhtml mimetype /= serve xhtml with the html mimetype But suppose you made a typo. And bear in mind again we are talking about specifically xhtml 1.0, and furthermore with restrictions. serve xhtml with the html mimetype, call this xhtml is not absurd. The syntax is xhtml. serve xhtml with the html mimetype, call this html is not absurd. A bit of a kludge, yes --- officially blessed kludge, mind you. But not absurd. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
We all seem to understand that there are a complex of issues surrounding the HTML and XHTML dialects, doc types, MIME Types, and file extensions. It is a tangle of intentions and compatibility issues, and one where experts and standards writers admit to practical compromises, which at times are even contradictory. The choice to generate Haddock output as XHTML 1.0 Transitional and Frames, stored into files with an extension of .html, and that would likely be served as text/html, was mine and I did so with review of current best practices. The output Haddock now generates renders correctly and consistently in all browses in use by the Haskell community (Firefox, Chrome, Safari, Opera, IE 6, IE 7, and IE 8), the Javascript is handled properly, and with one minor exception[1] it validates as served by the W3C. The main aim of the work was achieved: Being able to restyle the output with clear, semantic CSS, and do so in a way that works in all browsers, and all serving environments. If there is a particular issue that is causing the documentation generated to not be usable, please let me know. - Mark [1] John Milliken caught that anchor identifiers for groups didn't validate, though they did work in every browser. The fix is already coded and pushed to the development repo. The sample pages on my site updated. You can check the validation with: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.ozonehouse.com%2Fmark%2Fsnap-xhtml%2Fcontainers%2FData-Map.html This fix isn't crucial, and so I've recommended that we not produce a Haddock point release just for this.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On 10-09-04 05:46 PM, Jeremy Shaw wrote: Mark suggested that it was easier to achieve multi-browser compatibility using xhtml instead of html, but I am quite certain he is mistaken. There are really three different rendering modes found in browsers: 1. standards mode 2. quirks mode 3. xhtml mode By serving xhtml content as text/html, he is getting browsers to use quirks mode instead of standards mode. No. https://developer.mozilla.org/en/Mozilla%27s_DOCTYPE_sniffing http://reference.sitepoint.com/css/doctypesniffing ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unnecessarily strict implementations
On 10-09-03 06:11 AM, Henning Thielemann wrote: Yes, something this way. () suggests a notion of magnitude for me, which some orderings do not have. Like for example -1000 has a larger magnitude than -0.0001, therefore you also reject the common ordering -1000 -0.0001? http://groups.google.com/group/alt.algebra.help/browse_frm/thread/87ca3963373ddeb5 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
I will be going into a situation where there are tasks that have yet to be automated, so I will be going after that before re-writing anything. But if I can come up with here's why, there will be less eyebrows raised. Thanks for all feedback so far. On Sat, Sep 4, 2010 at 10:21 AM, Gaius Hammond ga...@gaius.org.uk wrote: My usual rhetoric is that one-off, throwaway scripts never are, and not only do they tend to stay around but they take on a life of their own. Today's 10-line file munger is tomorrow's thousand-line ETL batch job on which the business depends for some crucial data - yet the original author is long gone and no-one dares modify in case it breaks. So it is just good sense to use sound practices from the very beginning. One of the features of Perl is that it will try to work even if you make type errors (e.g. give it a scalar in place of a list, or a string instead of an int). One day, however, it WILL fail. Haskell finds these types of bugs upfront, and not when your pager goes off at 3am... Cheers, G --Original Message-- From: Michael Litchard Sender: haskell-cafe-boun...@haskell.org To: haskell-cafe@haskell.org Subject: [Haskell-cafe] help me evangelize haskell. Sent: Sep 4, 2010 17:38 I'll be starting a new job soon as systems tool guy. The shop is a perl shop as far as internal automation tasks go. But I am fortunate to not be working with bigots. If they see a better way, they'll take to it. So please give me your best arguments in favor of using haskell for task automation instead of perl, or awk or any of those scripting lanugages. ___ 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] help me evangelize haskell.
On Sat, Sep 4, 2010 at 5:53 PM, Michael Litchard mich...@schmong.org wrote: I will be going into a situation where there are tasks that have yet to be automated, so I will be going after that before re-writing anything. But if I can come up with here's why, there will be less eyebrows raised. Thanks for all feedback so far. Perhaps give this talk: http://donsbot.wordpress.com/2010/08/17/practical-haskell/ Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] help me evangelize haskell
Michael: Hi. I take the risk to mention some facts you might already be working on. I speculate on three perceptions in the mind of decision makers related to the adoption of a new language in a shop. This perceptions can be modified in stages. First Stage: Awareness. Why programming in that language matters? Once you can justified this, advance to the following stage. Haskell is nice, quick to develop, brings tools to make abstractions at any level and has tools and libraries. And community support is really awesome! If you invest more in learning, you can strive to use it as formal programming method and earn safety guarantees. Please, see elsewere for success stories that help you to motivate and encourage management to test the new alternative. Second Stage: Small term engagment. Why your shop should do little investment in trying a new language in a small but representative project? Here you can make two arguments to gain support in this stage: 2.A) The shortcommings of the current tools/languages. 2.B) Small concept programs of how your current language/tool would fail where the new one would success. You can gain credibility by showing how your new tool could be short on some aspect that it's well mastered in the old one. (i.e. be impartial). Someone has already pointed how fragile interpreted programs are. In this stage you must gain both decision makers and peers recognition of the problem the shop is facing with the current language versus the improvements of using the new language. A project must be acomplished and reviewed, so a decision can be made over the facts of costs and benefits. Third Stage: Adoption. Is it really better to adopt a new language? At this point you have evidence of possible benefits and costs. And a decision is made. Among other costs, please take in account that embracing any new language in a shop will require formalised (funded, time alloted to, machines, any other resource) learning and coaching activities. Haskell has long learning curve. And you must consider this cost of being less productive than in your current language. There's too the risk of hitting walls in a tight-schedule situation. You can lower this risk of failure if you arrange to have a mentor (master) who can lead, provide hints to co-workers, discuss approaches and solve hard issues whenever they appear. Counter-arguments that you must deal with: c1) Why not... Erlang? F#? See Jon Harrop's claims. Scala or Clojure? c2) Performance predictability. c3) On the fly script generation and execution. c4) Will your co-workers be happy of embracing a new paradigm of solving problems? Will type signatures appear as pain or a valuable thing to them? -- Leonel Fonseca. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Thu, Sep 2, 2010 at 11:14 PM, Mark Lentczner ma...@glyphic.com wrote: I am well aware of the differences between HTML and XHTML. I choose to switch Haddock's output from HTML to XHTML mostly because I have found the consistency of rendering cross-browser to be greater and easier to achieve with XHTML. I'm not alone in this opinion: Many well respected web design authorities have promoted, and publish their own sites, in XHTML.[1] Even Microsoft's own developer web site uses it[2]! I am very glad for the new CSS based layout! Thanks! I am very dubious that switching from HTML to XHTML makes anything more consistent. If you have a counter example I would love to see it, because this is an issue that affects my daily work. Here is why I am dubious. Browsers that support html and xhtml have two different code paths for rending html vs xhtml. The *only* way to select which code path is taken is by specifying the mime-type when you serve it. Either application/xml or text/html. So, if you take xhtml and serve it as text/html, then the browser will treat it as html and send it to the html code rendering path. In other words, it will send it down a code path that knows nothing about xhtml. The reason it works at all is because browsers do their darnest to make it render. So in xhtml you might have a tag like: br / Which, in xhtml, is short for br/br. When you send it down the html path, it the html render will see it as: br / That is, it will see it as the normal br tag with a bogus attribute named /. Now, perhaps you can understand why I am dubious? Whether or not you send html or xhtml, it is being rendered by the same code that only understands html. So it is hard to see how adding bogus attributes like / to elements is going to improve cross browser compatibility. You are basically saying that if you add bogus markup to your html that the browser ignores, it is works more reliably than producing valid html. The fact that the bogus markup happens to make it valid xhtml is unimportant, because the code path knows nothing of xhtml anyway. If you converted the current code from xhtml to html, and anything changes in the rendering, I, for one, will be shocked, and very curious about why that happened. Also, if you plan to eventually migrate to the x/html 5, that spec says: generally speaking, authors are discouraged from trying to use XML on the Web Since the Web Hypertext Application Technology Working Group is full of people that actually develop browsers, I think their opinion carries some weight ;) Anyway, I expect the use of xhtml (served as text/html) instead of valid html in haddock will have no negative effects for me whatsoever. But the use of CSS will be a big win! So thanks again for doing that! - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/4/10 21:27 , Jeremy Shaw wrote: Here is why I am dubious. Browsers that support html and xhtml have two different code paths for rending html vs xhtml. The *only* way to select which code path is taken is by specifying the mime-type when you serve it. Either application/xml or text/html. XHTML starts with a !DOCTYPE. You've just asserted that no browser is capable of noticing that and responding to it even though it's right at the start, while somehow managing to support META HTTP-EQUIV=... tags buried in the HEAD that can force it to go back and start from scratch. Really? Or have we all been imagining the latter for the past, oh, 15 or so years? (Mozilla had a serious bug relating to that restart for years; I assure you it's not a fantasy.) I wouldn't be surprised if HTML and XHTML ultimately follow different rendering paths --- but your assertions are raising red flags and smell suspiciously like ideology taking offense at reality not automatically constraining itself to fit in its assigned pigeonhole. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyC9qsACgkQIn7hlCsL25U8uACfdDA4RLUv5LedObrIaO4DpQE1 0CMAnj5ntJ6dhRju5sCw7IGfor68Aaa4 =TaCL -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Sat, Sep 4, 2010 at 8:47 PM, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/4/10 21:27 , Jeremy Shaw wrote: Here is why I am dubious. Browsers that support html and xhtml have two different code paths for rending html vs xhtml. The *only* way to select which code path is taken is by specifying the mime-type when you serve it. Either application/xml or text/html. XHTML starts with a !DOCTYPE. You've just asserted that no browser is capable of noticing that and responding to it even though it's right at the start, while somehow managing to support META HTTP-EQUIV=... tags buried in the HEAD that can force it to go back and start from scratch. Really? Browsers *could* look at the doctype to pick the path. But they *do not*. What they look at is the http header that is sent before the response body is even parsed. (Obviously, things are a little different if it is reading a file from the disk). For example, if you do, curl -v http://www.w3.org/, you will see this: Content-Type: text/html; charset=utf-8 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en Where the, Content-Type: text/html; charset=utf-8, is an HTTP response header. Rather than second guess what the response body is, the browsers consider that content-type header to be authoritative over the meta / tag. (http://www.dev-archive.net/articles/xhtml.html#types) If you open that url in firefox, and go to, Tools Page Info, it will tell you: Type: text/html Render Mode: Standards Compliance Mode Encoding: utf-8 Meaning that even though it has the xhtml doctype (clearly shown in the curl output), firefox is only paying attention to the text/html content type. If you visit this page, http://www.echoofeden.com/htmlTests/xhtmlFix/index.xhtml Then it shows: Type: application/xhtml+xml Or, perhaps more relevant is this page: http://www.schillmania.com/content/entries/2004/10/24/application-xhtml+xml/invalid-xml.xml Which contains an xml error. You can tell it is using the XML rendering path, because it correctly gives an error instead of trying to guess what you mean and rendering the page anyway. Now, in the case of firefox. If you serve an xhtml with the DOCTYPE as text/html, it will trigger the use of the text/html renderer. If the DOCTYPE is xhtml 1.0 transition, then the browser will sniff that and use 'almost standards' mode. Which is exactly like the normal text/html standards mode except for one thing: the layout of images inside table cells is handled as they are in Gecko's quirks mode. (https://developer.mozilla.org/en/Gecko's_Almost_Standards_Mode). Everything I have ever read says that browsers only look at the content-type header to choose html vs xhtml rendering. And the supporting evidence seems to indicate that is true. If you have contrary evidence I would be glad to hear it. It's really difficult to find reliable information on this topic. - jeremy Or have we all been imagining the latter for the past, oh, 15 or so years? (Mozilla had a serious bug relating to that restart for years; I assure you it's not a fantasy.) I wouldn't be surprised if HTML and XHTML ultimately follow different rendering paths --- but your assertions are raising red flags and smell suspiciously like ideology taking offense at reality not automatically constraining itself to fit in its assigned pigeonhole. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyC9qsACgkQIn7hlCsL25U8uACfdDA4RLUv5LedObrIaO4DpQE1 0CMAnj5ntJ6dhRju5sCw7IGfor68Aaa4 =TaCL -END PGP SIGNATURE- ___ 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] ANNOUNCE: Haddock version 2.8.0
On Sat, Sep 4, 2010 at 14:46, Jeremy Shaw jer...@n-heptane.com wrote: So the choices are: 1. only focus on getting the xhtml 1.0 served as application/xml working correctly, and ie users get nothing.. 2. create xhtml 1.0 that would work correctly if served as application/xml, but serve it as text/html, and ignore that fact that some stuff might not be rendering correctly when treated as text/html. 3. create xhtml documents which render correctly whether served as application/xml or text/html, but then only serve them as text/html anyway 4. forget about how the xhtml documents render as application/xml, and only focus on how they render as text/html. 5. Do as my patch does; default to HTML 4 (supported by all browsers), and allow users to generate correct XHTML if they want/need to. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to catch exception within the Get monad (the Binary package)
Hi, The following function* is supposed to decode a list of some serialized objects following each other in a lazy Bytestring: many :: Get a - Get [a] many prs = many' [] where many' a = do s - prs r - isEmpty case r of True - return (reverse a) False - many' (s:a) prs is a parser to decode a single object. If however something goes wrong, and prs fails, the whole function fails (error is thrown). Since [a] (result of decoding) is a lazy list, actual exception may be thrown at any moment the list is being processed, and exception handler may not be properly set. Is there any way to catch/detect failures inside the Get monad? It is not an instance of MonadError, so catchError does not work. Ideally, the function would keep decoding as long as it is possible, and upon the first failure of the parser, return whatever has been decoded. Thanks. --- * there is one intentional inaccuracy in this function: isEmpty is called _after_ decoding is tried, so an empty ByteString would cause parser failure and exception right away; this is used as a test case. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
On 5 September 2010 03:34, David Menendez d...@zednenem.com wrote: On Fri, Sep 3, 2010 at 8:23 AM, John Lato jwl...@gmail.com wrote: Do you have a kind * implementation of Foldable? I'd be interested in seeing it, because I was unable to create a usable implementation (based upon the RMonad scheme) on my last attempt. I always figured it would look something like: class Foldable f where type Elem f :: * foldMap :: Monoid m = (Elem f - m) - f - m with the usual definitions for foldr, foldl, etc. +1 for using the proper constraints, and especially for bringing over Pointed (and anything else that applies). What's the argument for Pointed? Are there many types which are instances of Pointed but not Applicative? Are there many algorithms which require Pointed but not Applicative? Presumably just that it's another possible abstraction. -- 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
