Re: [Haskell-cafe] Restricted type classes
On 9/5/10 10:19 AM, Ivan Lazar Miljenovic wrote:
Hmmm is there any reason for Functor to be a superclass of
Pointed? I understand Functor and Pointed being superclasses of
Applicative (which in turn is a superclass of Monad), but can't see
any relation between Pointed and Functor...
Because there's a law for pointed functors which ensures that return
(point, unit, pure,...) only creates trivial structure:
forall {A B : Type} (f : A - B) (a : A)
, fmap f (return a) = return (f a)
If we require this law, then the five laws for Applicative can be
reduced to only three; which is nice. (Though, if the extra two laws are
satisfied, then we can prove this one.)
We don't actually enforce that instances obey their class' laws anywhere
else, so it's not like we'd need somewhere to store this proof. But the
law is there nevertheless. What use would it be to have a return
function that doesn't satisfy any laws (i.e., without fmap)?
--
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 6 September 2010 16:15, wren ng thornton w...@freegeek.org wrote:
On 9/5/10 10:19 AM, Ivan Lazar Miljenovic wrote:
Hmmm is there any reason for Functor to be a superclass of
Pointed? I understand Functor and Pointed being superclasses of
Applicative (which in turn is a superclass of Monad), but can't see
any relation between Pointed and Functor...
Because there's a law for pointed functors which ensures that return (point,
unit, pure,...) only creates trivial structure:
forall {A B : Type} (f : A - B) (a : A)
, fmap f (return a) = return (f a)
If we require this law, then the five laws for Applicative can be reduced to
only three; which is nice. (Though, if the extra two laws are satisfied,
then we can prove this one.)
We don't actually enforce that instances obey their class' laws anywhere
else, so it's not like we'd need somewhere to store this proof. But the law
is there nevertheless. What use would it be to have a return function that
doesn't satisfy any laws (i.e., without fmap)?
Well, if we consider what this does, pure is equivalent to singleton
for container types. The actual definition of pure (or any other
aspect of Pointed) doesn't require Functor; however there are
properties for types that are instances of Functor and Pointed.
So, from a proof/testing POV having Functor as a superclass is nice;
from an implementation POV it doesn't seem to be needed.
--
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] Re: [Haskell] Proposal: Form a haskell.org committee
2010/9/6 Manuel M T Chakravarty c...@cse.unsw.edu.au: Ian Lynagh: To fix this problem, we propose that we create a haskell.org committee, which is responsible for answering these sorts of questions, although for some questions they may choose to poll the community at large if they think appropriate. [..] Unfortunately, this gives us a bootstrapping problem, so we suggest that the initial committee be chosen from open nominations by some of the people who currently de-facto end up making the decisions currently: Duncan Coutts, Isaac Jones, Ian Lynagh, Don Stewart and Malcolm Wallace. These 5 would still be elligible to nominate themselves. Two of the initial members will stand down after one year, and two after two years, in order to bootstrap rolling membership turnover. Good plan! Manuel Seems very good, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
On 6 September 2010 03:46, Mathew de Detrich dete...@gmail.com wrote: If they are perl programmers, they (should) understand perl very well. I would suggest to try explaining to them the obvious disadvantages of perl and the way that Haskell can cover those disadvantages without (much) of a compromise. Now that's going to go down well... Maybe the original poster might want to soak up the company culture for a while before than telling co-workers how to do things. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Proposal: Form a haskell.org committee
Ian et al | To fix this problem, we propose that we create a haskell.org | committee, which is responsible for answering these sorts of questions, | although for some questions they may choose to poll the community at | large if they think appropriate. I think that's an excellent idea. I think there should be a web page describing what the committee does, who is in it, how to contact it, etc. I'm sure you intended that. An annual statement of what money came in and went out would be good practice. Well the committee also be responsible for the haskell.org web site? | We suggest that the committee be composed of 5 representatives from the | community, with committee members standing down after at most 3 years. | Each year the committee will appoint one of their members to be the chair. It's usually helpful to establish a rotation so that everyone knows who is going to stand down when, and to arrange that there isn't a sudden glut one year. Document the stand-down dates on the committee web page. In my experience, everyone forgets! Five might be a little small. It might be good to allow for a person to be re-elected for a second term if they are willing. It's a good principle to have rotation, but a pity to lose willing and experienced talent. But six years is enough. | As membership of the Haskell community is not well-defined, and voting | would potentially be open to abuse if anyone were able to vote, we | propose that the committee should choose their replacements from open | nominations. I agree with the problem, and I think your proposed solution may do for now, but it's obviously not a robust solution. I trust you five, but in three years time you may all have stood down! A possible solution would be to have an electoral college of people entitled to vote. It should be easy to become a member of the college: any track record of contributions to the Haskell community, including constructive contributions to Haskell Cafe, would be enough. Then the college can elect the committee. It's debatable whether this is worth the bother at this point. Maybe it would be enough to document on the committee page that we don't regard the nomination process as robust, and if any concern arises we will consider something more substantial. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PhD position at the Software Technology group at Utrecht University
There is currently a PhD position available at he Software Technology group, Department of Information and Computing Sciences, Utrecht University, Netherlands. The ST group focusses its research on programming methodologies, compiler construction, and program analysis. In this area the research will take place, in particular the topic is semi-automatic incrementalization of programs narrowed down to our Utrecht Haskell Compiler (UHC), using our Attribute Grammar system (UUAG). For more details and application see http://www.academictransfer.com/employer/UU/vacancy/6114/lang/en/ The application deadline is October 5, 2010. Please contact Prof. Dr. S.D. Swierstra at doai...@cs.uu.nl for more information. The project is funded by a research grant from the Netherlands 'Organization for Scientific Research’ (NWO). Best regards, - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 | Email: a...@cs.uu.nl / |___\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] running ghci simply
Is there a way to run a Haskell module via ghci with a single command on the command-line? Note: I'm on Windows XP. If I have the module test.hs, I can type test.hs and that will load it into ghci. However, I need to then type main to run it, and then manually exit ghci. I would like to do all this in one step. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] running ghci simply
On 6 September 2010 17:42, Johann Bach johann.bach1...@gmail.com wrote: Is there a way to run a Haskell module via ghci with a single command on the command-line? Note: I'm on Windows XP. If I have the module test.hs, I can type test.hs and that will load it into ghci. However, I need to then type main to run it, and then manually exit ghci. I would like to do all this in one step. Not sure if this will work in Windows, but you might be able to use runhaskell/runghc to run the script. -- 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] running ghci simply
2010/9/6 Ivan Lazar Miljenovic ivan.miljeno...@gmail.com: On 6 September 2010 17:42, Johann Bach johann.bach1...@gmail.com wrote: Is there a way to run a Haskell module via ghci with a single command on the command-line? Note: I'm on Windows XP. If I have the module test.hs, I can type test.hs and that will load it into ghci. However, I need to then type main to run it, and then manually exit ghci. I would like to do all this in one step. Not sure if this will work in Windows, but you might be able to use runhaskell/runghc to run the script. Or ghc -e main test.hs Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] running ghci simply
2010/9/6 Johann Bach johann.bach1...@gmail.com: On Mon, Sep 6, 2010 at 12:51 AM, Vo Minh Thu not...@gmail.com wrote: 2010/9/6 Ivan Lazar Miljenovic ivan.miljeno...@gmail.com: On 6 September 2010 17:42, Johann Bach johann.bach1...@gmail.com wrote: Is there a way to run a Haskell module via ghci with a single command on the command-line? Note: I'm on Windows XP. If I have the module test.hs, I can type test.hs and that will load it into ghci. However, I need to then type main to run it, and then manually exit ghci. I would like to do all this in one step. Not sure if this will work in Windows, but you might be able to use runhaskell/runghc to run the script. Or ghc -e main test.hs Cheers, Thu This seems to work. Regarding runhaskell: the last time I tried it, it compiled the program, but I want to use the interpreter. I have a script-like application in which the code will be changing frequently and I want to run it and see the results quickly. In this case, you might want to open it once in ghci and use the :r (for reload) each time you want to try a modification. This way, ghci will be quite quick to tell you any parse or type error. Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] running ghci simply
On 6 September 2010 18:00, Johann Bach johann.bach1...@gmail.com wrote: Regarding runhaskell: the last time I tried it, it compiled the program, but I want to use the interpreter. I have a script-like application in which the code will be changing frequently and I want to run it and see the results quickly. Unless on Windows it does something differently, that shouldn't happen: on *nix it just interprets the file and doesn't compile it. -- 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] Unnecessarily strict implementations
Daniel Fischer schrieb: On Sunday 05 September 2010 21:52:44, Henning Thielemann wrote: Daniel Fischer schrieb: Yes. Ordinarily, lines in text files aren't longer than a few hundred characters, leaking those, who cares? I got several space leaks of this kind in the past. They are very annoying. They are especially annoying if input comes from the outside world, where people can attack them to crash your program because of memory exhaustion. That would likely be the case of long lines, wouldn't it? I have trouble imagining a scenario where `lines' holding on to a few hundred characters which could already be released causes a noticeable space leak, let alone memory exhaustion. I talked about an _attack_! I provide a program that processes external data (say a webserver, for instance one for an ICFP contest) and someone feeds it intentionally with megabytes of text without any line ending. ___ 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 - HTML vs. XHTML
Mark Lentczner schrieb: 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. I use KDE's Konqueror, which I like much more than Firefox, because it allows me to easily browse between WWW and local files, shows highlighted source code, disk consumption of directories, dia shows etc. In my opinion focusing on a small set of assumed popular browsers and complying to their quirks is the wrong way. It seems to me that browsers become popular because web authors choose to support their quirks and bugs. It would be better if browsers would comply to the standards and web authors do so as well. All these incompatibilities between browsers and common abuse in HTML and XHTML make it a nightmare for me to process web documents as in my online web-site enhancement :-) service: http://www.haskell.org.monadtransformer.parallelnetz.de/haskellwiki/Category:Monad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] overloaded list literals?
I think left-biased (= singly linked) lists are much overrated in Haskell coding (and teaching). The language (syntax and Prelude) makes it just too easy to use them, and old habits (from LISP) die hard. Sure, lists serve a purpose: * they model (infinite, lazy) streams, used in the producer/transformer/consumer pattern * they are an algebraic data type, so you can use them to teach recursion ((co-)induction); but more often, lists are (mis-)used when actually * you want some efficiently index-able and concat-able sequence type * or you don't need the indexing, just membership, so you actually want Data.Set (disregarding strictness and unwanted Ord instances for the moment). It is an empirical law that in 90 percent of the cases where a computer science student says list he means set. * you avoid/forget to tell your students about algebraic data types in general. Hypothetically now ... We have overloaded numerical literals (Num.fromInteger) and we can overload string literals (IsString.fromString), so how about using list syntax ( [], : ) for anything list-like (e.g., Data.Sequence)? Of course some minor details would need to be worked out, like what methods should go in the hypothetical class IsList (is is Foldable?) and what to do about pattern matching (perhaps we don't need it?) IIRC there was a time when list comprehension would actually mean monad comprehension (when there was no do notation) but that's not what I'm getting at here. Or is it? Do we have a Haskell museum of ideas from the past? Best - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] overloaded list literals?
On Mon, 6 Sep 2010, Johannes Waldmann wrote: We have overloaded numerical literals (Num.fromInteger) and we can overload string literals (IsString.fromString), so how about using list syntax ( [], : ) for anything list-like (e.g., Data.Sequence)? My favorite solution would be to throw away special list syntax and list comprehensions at all. Then lists and sets are on the same level of compiler support. If find 1:2:3:4:5:[] a perfect way to write lists. Analogously to this we could have an infix operator that is overloaded with (:) for lists and Set.insert for sets. Of course some minor details would need to be worked out, like what methods should go in the hypothetical class IsList (is is Foldable?) and what to do about pattern matching (perhaps we don't need it?) View patterns? IIRC there was a time when list comprehension would actually mean monad comprehension (when there was no do notation) but that's not what I'm getting at here. Or is it? Do we have a Haskell museum of ideas from the past? I think the future ideas collected at the old Hawiki would serve as such museum. Unfortunately Hawiki is gone. I wonder whether I can easily get a dump of HaskellWiki in order to prevent it from the same destiny. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] overloaded list literals?
On 06/09/10 11:23, Johannes Waldmann wrote: We have overloaded numerical literals (Num.fromInteger) and we can overload string literals (IsString.fromString), so how about using list syntax ( [], : ) for anything list-like (e.g., Data.Sequence)? I would have thought you have two obvious choices for the type-class (things like folding are irrelevant to overloading list literals): class IsList f where fromList :: [a] - f a or: class IsList f where cons :: a - f a - f a empty :: f a I'd go for the first, as I'd imagine you are only overloading the [a,b,c] form, not the a:b:c:[] form, and the first reflects this better. Both of these could be used to convert a list literal into a list-like type (e.g. Sequence). But neither of them would be useful for sets or maps, because the classes lack an Ord constraint on the type a -- maybe this makes overloaded list literals fairly limited in utility. Thanks, Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
I Think you misinterpreted what I said. I didn't say you should tell the programmers how to code, I said you should show the perl coders how Haskell has advantages over pearls without much cost On 06/09/2010 5:21 PM, Stephen Tetley stephen.tet...@gmail.com wrote: On 6 September 2010 03:46, Mathew de Detrich dete...@gmail.com wrote: If they are perl programme... Now that's going to go down well... Maybe the original poster might want to soak up the company culture for a while before than telling co-workers how to do things. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org h... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] overloaded list literals?
Hello Johannes, Monday, September 6, 2010, 2:23:35 PM, you wrote: i had such idea several years ago and proposed to name class ListLike. this class was finally implemented by John Goerzen and it does everything we can w/o changing language the main thing about literals is that they need to be recognized also at left side of equations, so that length (s:xs) = 1 + length xs length [] = 0 will work for ByteStrings and arrays like it work for list. if it will be implemented, then most programs manipulating on lists/strings, can be converted to more efficient ones simply by replacing imports Haskell 1.0 views may be the way to go, virtually converting other containers to lists, back and forth. of course, only if these virtual conversions will be optimized away by smart compiler I think left-biased (= singly linked) lists are much overrated in Haskell coding (and teaching). The language (syntax and Prelude) makes it just too easy to use them, and old habits (from LISP) die hard. Sure, lists serve a purpose: * they model (infinite, lazy) streams, used in the producer/transformer/consumer pattern * they are an algebraic data type, so you can use them to teach recursion ((co-)induction); but more often, lists are (mis-)used when actually * you want some efficiently index-able and concat-able sequence type * or you don't need the indexing, just membership, so you actually want Data.Set (disregarding strictness and unwanted Ord instances for the moment). It is an empirical law that in 90 percent of the cases where a computer science student says list he means set. * you avoid/forget to tell your students about algebraic data types in general. Hypothetically now ... We have overloaded numerical literals (Num.fromInteger) and we can overload string literals (IsString.fromString), so how about using list syntax ( [], : ) for anything list-like (e.g., Data.Sequence)? Of course some minor details would need to be worked out, like what methods should go in the hypothetical class IsList (is is Foldable?) and what to do about pattern matching (perhaps we don't need it?) IIRC there was a time when list comprehension would actually mean monad comprehension (when there was no do notation) but that's not what I'm getting at here. Or is it? Do we have a Haskell museum of ideas from the past? Best - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] overloaded list literals?
On Sep 6, 2010, at 12:23 PM, Johannes Waldmann wrote: We have overloaded numerical literals (Num.fromInteger) and we can overload string literals (IsString.fromString), so how about using list syntax ( [], : ) for anything list-like (e.g., Data.Sequence)? As lists of some type A represent the free monoid over A, what if [x,y,z] would be syntactic sugar for mconcat (map point (x:y:z:[])) with class Pointed p where point :: a - p a Then list literals could be used for every pointed monoid. Note that this only considers list literals. The (:) and [] constructors would not be overloaded. Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] overloaded list literals?
Am Montag, den 06.09.2010, 11:47 +0100 schrieb Neil Brown: I would have thought you have two obvious choices for the type-class (things like folding are irrelevant to overloading list literals): class IsList f where fromList :: [a] - f a or: class IsList f where cons :: a - f a - f a empty :: f a We should definitely get rid of these Is* class identifiers like IsString and IsList. We also don’t have IsNum, IsMonad, etc. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: countable-1.0
On Mon, 06 Sep 2010 03:46:18 -0700, Ashley Yakeley ash...@semantic.org wrote: countable: Countable, Searchable, Finite, Empty classes. class Countable, for countable types class AtLeastOneCountable, for countable types that have at least one value class InfiniteCountable, for infinite countable types class Searchable, for types that can be searched over class Finite, for finite types class Empty, for empty types data Nothing, an empty type Also includes these orphan instances: instance (Searchable a,Eq b) = Eq (a - b) instance (Finite a) = Foldable ((-) a) instance (Finite a) = Traversable ((-) a) instance (Show a,Finite a,Show b) = Show (a - b) Could you put these instances in a dedicated module? In the same vein I would like to have a newtype wrapper over functions were intention is to be used extensionally. Nice package BTW! -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] overloaded list literals?
Wolfgang, We should definitely get rid of these Is* class identifiers like IsString and IsList. We also don’t have IsNum, IsMonad, etc. I see your point. For strings, however, there was of course never the possibility to dub the class String as that name is already taken by the type synonym. In general, it is kind of unfortunate that type classes and type constructors share a namespace, even though there is no way to ever mix them up. Cheers, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
On Sun, Sep 5, 2010 at 7:18 PM, David Menendez d...@zednenem.com wrote: On Sun, Sep 5, 2010 at 8:40 AM, John Lato jwl...@gmail.com wrote: On Sat, Sep 4, 2010 at 12:34 PM, David Menendez d...@zednenem.com wrote: On Fri, Sep 3, 2010 at 8:23 AM, John Lato jwl...@gmail.com wrote: +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? Having Pointed is categorically the right thing to do, which is why I argue for its inclusion. Why is it categorically the right thing to do? Because it's the proper abstraction underlying Applicative and Monad, as far as I understand category theory. When Conor McBride was promoting the use of Applicative (then called Idiom), he provided several instances and algorithms showing that it was a useful generalization of Monad, and it still took several years and a few papers[1] before Applicative found its way into the standard library. In other words, we didn't add Applicative and then discover Traversable later. Traversable was a big part of the argument for why Applicative is useful. I take this in favor of my point. Applicative wasn't considered useful, so it wasn't included. Then Conor McBride shows that it is useful, but at that point it was too late and now we're stuck with pure, return, ap, liftA2, liftM2, etc. [1] Idioms: applicative programming with effects http://www.cs.nott.ac.uk/~ctm/Idiom.pdf Also, I think it would be prudent to avoid a situation with the possibility of turning into a rehash of the Functor/Applicative/Monad mess. Granted, but let's not rush blindly in the opposite direction. Are there any good reasons for not including it? Just because we don't have a use now doesn't mean it might not be useful in the future. This is an argument for putting every member of the container API into its own independent class. Why make things more complicated for little or no benefit? Not every member, but I would argue that type classes for containers should be much more fine-grained than anything I have seen proposed so far. I'm thinking of the collections provided by the .Net framework, i.e. a base ICollection interface, then IEnumerable, IList, and ISet on top of them. If an algorithm needs a list interface (integer-indexed, etc.), it can specify IList in the context, whereas if it only needs e.g. to check the length, or that a container is non-null, it can just specify ICollection and work with more data structures. I would be in favor of breaking it down further, and then the ListClass, SetClass, etc. would likely be classes with no methods, just a particular combination of superclasses. Edison is a good model too, although again I would go further. One category of containers that is currently impossible to express (with container-classes or Edison) is non-null data, e.g. SafeList. Adding support for these would be nice, and it would be easier with finer-grained dependencies. As an example, a List interface could work for both regular lists and SafeList's, but only if it didn't require Monoid (or similar) as a superclass constraint. That's hard to do with the current structure, but if you're just combining several type classes it's easy. At a minimum, I think that having extra classes for the specifics of e.g. Map or Queue interfaces is required for maximum utility. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] overloaded list literals?
On Mon, 6 Sep 2010, Stefan Holdermans wrote: Wolfgang, We should definitely get rid of these Is* class identifiers like IsString and IsList. We also don’t have IsNum, IsMonad, etc. I see your point. For strings, however, there was of course never the possibility to dub the class String as that name is already taken by the type synonym. StringLike would have been an alternative.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graphics.Drawing
On Sep 6, 2010, at 1:57 PM, han wrote: So the question is: Do you agree that Graphics.Rendering.OpenGL actually should have been Graphics.OpenGL (or just OpenGL) for wieldiness? If you don't, what is your reason? I would like to know. Often, when this topic comes up, someone claims that ontology is overrated [1]. This time it's me. Sebastian [1]: http://www.shirky.com/writings/ontology_overrated.html -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help me evangelize haskell.
Hi All, Not a complete guide, but just something, which can help: Perl6 is inspired by haskell. That was, how I end up by haskell. And I believe a lot of people of the perl community got interested in haskell that way. Maybe this works for some of collegues too. I still like perl, but haskell is in many cases more productive. On the other hand perl has more libs. Greets, Edgar On Mon, Sep 6, 2010 at 12:50 PM, Mathew de Detrich dete...@gmail.comwrote: I Think you misinterpreted what I said. I didn't say you should tell the programmers how to code, I said you should show the perl coders how Haskell has advantages over pearls without much cost On 06/09/2010 5:21 PM, Stephen Tetley stephen.tet...@gmail.com wrote: On 6 September 2010 03:46, Mathew de Detrich dete...@gmail.com wrote: If they are perl programme... Now that's going to go down well... Maybe the original poster might want to soak up the company culture for a while before than telling co-workers how to do things. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org h... ___ 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] Graphics.Drawing
On 6 September 2010 21:57, han e...@xtendo.org wrote: So the question is: Do you agree that Graphics.Rendering.OpenGL actually should have been Graphics.OpenGL (or just OpenGL) for wieldiness? I think Graphics.OpenGL would have sufficed, unless there was sufficient reason to want to group it with other rendering-specific modules. Admittedly, I'm biased, in that I proposed a new top-level Graph.* namespace on the libraries mailing list and out of those few that responded the main response was that there was no point in such a new top-level namespace. -- 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] overloaded list literals?
On Sep 6, 2010, at 1:47 PM, Stefan Holdermans wrote: In general, it is kind of unfortunate that type classes and type constructors share a namespace, even though there is no way to ever mix them up. Class and type names mix in im- and export lists. IIRC, this is the reason for putting them in a common name space. -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] AngloHaskell 2010 - Final Reminder + Wi-Fi Sign-Up
AngloHaskell 2010 is this week! AngloHaskell 2010 - 5th Annual Haskell Meeting in England Friday September 10th and Saturday September 11th, 2010 Microsoft Research, Cambridge, UK http://www.haskell.org/haskellwiki/AngloHaskell/2010 AngloHaskell is a free gathering of all people Haskell-related from beginners to seasoned hackers, both academic and industrial. AngloHaskell 2010 is generously hosted by Microsoft Research. As a result no charge is made for attending or speaking. Friday will be a day of talks and discussion at MSR followed by a more informal day of activities on Saturday somewhere else in Cambridge. AngloHaskell welcomes talks on all Haskell related subjects. From short comments (Functional Grit) to full presentations, all are welcome. Please add your name and the title of your talk to the wiki page (or email me and I will add it for you). If you want to attend please add your name to the wiki page, or let me know by email. Even if you can't attend you can add you name to the Not this year, but hopefully next! section. Wi-Fi accounts (at Microsoft Research on Friday) are available on request. The sign-up deadline is Wednesday 8th September so please sign-up on the wiki page or email me (with Full Name, Institution, Country of Residence and Email Address). Organisational discussions are on held on the #anglohaskell channel on the Freenode IRC network, feel free to drop in with questions or comments. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unnecessarily strict implementations
On Monday 06 September 2010 10:47:54, Henning Thielemann wrote: Daniel Fischer schrieb: On Sunday 05 September 2010 21:52:44, Henning Thielemann wrote: Daniel Fischer schrieb: Yes. Ordinarily, lines in text files aren't longer than a few hundred characters, leaking those, who cares? I got several space leaks of this kind in the past. They are very annoying. They are especially annoying if input comes from the outside world, where people can attack them to crash your program because of memory exhaustion. That would likely be the case of long lines, wouldn't it? I have trouble imagining a scenario where `lines' holding on to a few hundred characters which could already be released causes a noticeable space leak, let alone memory exhaustion. I talked about an _attack_! I provide a program that processes external data (say a webserver, for instance one for an ICFP contest) and someone feeds it intentionally with megabytes of text without any line ending. Yes, that's absolutely a problem. I was irritated/confused by the selection of text you quoted which was only about the ordinary case of relatively short lines. I didn't originally think about an attack but only about accidental long lines, which make it important enough to fix lines' leak. Throw a possible attack in, and it's urgent to fix it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: [Haskell] Proposal: Form a haskell.org committee
Simon Peyton-Jones wrote: | As membership of the Haskell community is not well-defined, and voting | would potentially be open to abuse if anyone were able to vote, we | propose that the committee should choose their replacements from open | nominations. I agree with the problem, and I think your proposed solution may do for now, but it's obviously not a robust solution. I trust you five, but in three years time you may all have stood down! A possible solution would be to have an electoral college of people entitled to vote. It should be easy to become a member of the college: any track record of contributions to the Haskell community, including constructive contributions to Haskell Cafe, would be enough. Then the college can elect the committee. It's debatable whether this is worth the bother at this point. Maybe it would be enough to document on the committee page that we don't regard the nomination process as robust, and if any concern arises we will consider something more substantial. FWIW, the IETF faces the same situation, and addresses it through a Nominating Committee (NomCom) mechanism, which for the most part has worked well for many years (http://tools.ietf.org/html/rfc3777). #g ___ 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 - HTML vs. XHTML
On Sep 6, 2010, at 2:40 AM, Henning Thielemann wrote: ... focusing on a small set of assumed popular browsers ... I didn't want to assume either. I ran a survey of the Haskell community and got over a 150 responses. The multiple choice browser question yielded: Firefox: 59% Chrome: 51% Safari: 24% Other: 11% Opera:7% IE 8: 2% IE 7: 1% IE 6: 1% As I did the work on Haddock, I tested the results on five browser/os combinations on my own machines, and about 30 browser/os combinations via browsershots[1]. and complying to their quirks is the wrong way. I believe the only sop to browser quirks in the current Haddock output are three lines of CSS that came from YUI 3: CSS Fonts [2] to achieve consistent font sizing in IE. These are well researched and minimal. There were a few times where I tried something (usually a choice of markup and CSS) that looked nice in WebKit browsers (Safari and Chrome), but didn't work in Firefox or others. In those cases I retreated to other approaches. A notable example is the Portability box in the upper right. I wanted that to be a dl list, and could get it to style nicely in all browsers except Firefox on Linux! I retreated to a table in that case. Since both the thing I tried and the result were valid markup and CSS, I'm hoping you won't consider this a major concession to quirks. All these incompatibilities between browsers and common abuse in HTML and XHTML make it a nightmare for me to process web documents as in my online web-site enhancement :-) service: http://www.haskell.org.monadtransformer.parallelnetz.de/haskellwiki/Category:Monad An excellent service! I hope the new, cleaner markup of Haddock works with less pain. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark [1] http://browsershots.org/ [2] http://developer.yahoo.com/yui/3/cssfonts/___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
Message: 20 Date: Sat, 04 Sep 2010 03:40:49 -0400 From: wren ng thornton w...@freegeek.org Subject: Re: [Haskell-cafe] Restricted type classes To: Haskell Cafe haskell-cafe@haskell.org Message-ID: 4c81f801@freegeek.org Content-Type: text/plain; charset=UTF-8; format=flowed On 9/3/10 12:16 AM, Ivan Lazar Miljenovic wrote: 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. Although I agree these do most things that people need, it's very rare that I need a data structure that guarantees *only* these features. Most often I need a map, a queue, etc. because I need either lookup by key, queue properties, etc. I think it's necessary to include classes like Indexable and Queue. Indexable may need to be split into two, one for ordered-Int indexes (i.e. lists) and one for Maps. Just a few days ago I wanted to change the priority queue implementation in some code. This was painful because the different available implementations all have varying APIs, so I couldn't just change the imports. I've wanted to do this in other contexts as well (e.g. maps and tries). The perhaps more important use is for coding algorithms that depend upon map properties, queue properties, etc., but leaving the actual implementation polymorphic so it can be chosen by a higher level. If the purpose of this project is to present a common interface for containers, then I think you should start by seeing what are the most common containers (I would guess lists, sets, maps, and queues) with a goal of providing their specific functionality through classes. Then all the common stuff can be stripped out and provided by superclasses. Of course we already know a great deal of the common operations, e.g. Traversable and Foldable, and we make use of those abstractions. It's this last step of a common map interface, queue interface, etc. that's missing. If you're just going to provide stuff we already have, I don't really see the point. 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 Shouldn't it be: class Functor where fmap class Pointed where point class (Functor f, Pointed f) = PointedFunctor f where class PointedFunctor f = Applicative f where (*); --etc. class Applicative f = Monad f where (=); --etc. even I might omit PointedFunctor, though, because it doesn't add anything. If it is omitted, that just means your Applicative contexts are slightly longer. But please don't make Pointed depend on Functor - we've already seen that it won't work for Bloom filters. Cheers, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] overloaded list literals?
Hello Stefan, Monday, September 6, 2010, 3:47:11 PM, you wrote: In general, it is kind of unfortunate that type classes and type constructors share a namespace, even though there is no way to ever mix them up. btw, i also had proposal to automatically convert typeclasses used in type declarations into constraints, so that: putStr :: StringLike - IO () treated as putStr :: StringLike s = s - IO () and length :: ListLike a - Int treated as length :: ListLike (c a) = c a - Int Together with proposals i mentioned previously, it will allow to treat existing code dealing with lists/strings as generic code working with any sequential container type -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] overloaded list literals?
Hello Johannes, Monday, September 6, 2010, 2:23:35 PM, you wrote: so how about using list syntax ( [], : ) for anything list-like (e.g., Data.Sequence)? i'vwe found my own proposal of such type: http://www.mail-archive.com/haskell-cafe@haskell.org/msg15656.html -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
On Mon, Sep 6, 2010 at 5:11 PM, John Lato jwl...@gmail.com wrote: Message: 20 Date: Sat, 04 Sep 2010 03:40:49 -0400 From: wren ng thornton w...@freegeek.org Subject: Re: [Haskell-cafe] Restricted type classes To: Haskell Cafe haskell-cafe@haskell.org Message-ID: 4c81f801@freegeek.org Content-Type: text/plain; charset=UTF-8; format=flowed On 9/3/10 12:16 AM, Ivan Lazar Miljenovic wrote: 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. Although I agree these do most things that people need, it's very rare that I need a data structure that guarantees *only* these features. Most often I need a map, a queue, etc. because I need either lookup by key, queue properties, etc. I think it's necessary to include classes like Indexable and Queue. Indexable may need to be split into two, one for ordered-Int indexes (i.e. lists) and one for Maps. Just a few days ago I wanted to change the priority queue implementation in some code. This was painful because the different available implementations all have varying APIs, so I couldn't just change the imports. I've wanted to do this in other contexts as well (e.g. maps and tries). The perhaps more important use is for coding algorithms that depend upon map properties, queue properties, etc., but leaving the actual implementation polymorphic so it can be chosen by a higher level. If the purpose of this project is to present a common interface for containers, then I think you should start by seeing what are the most common containers (I would guess lists, sets, maps, and queues) with a goal of providing their specific functionality through classes. Then all the common stuff can be stripped out and provided by superclasses. Of course we already know a great deal of the common operations, e.g. Traversable and Foldable, and we make use of those abstractions. It's this last step of a common map interface, queue interface, etc. that's missing. If you're just going to provide stuff we already have, I don't really see the point. 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 Shouldn't it be: class Functor where fmap class Pointed where point class (Functor f, Pointed f) = PointedFunctor f where class PointedFunctor f = Applicative f where (*); --etc. class Applicative f = Monad f where (=); --etc. even I might omit PointedFunctor, though, because it doesn't add anything. If it is omitted, that just means your Applicative contexts are slightly longer. But please don't make Pointed depend on Functor - we've already seen that it won't work for Bloom filters. Cheers, John I think most people have been using Pointed merely as shorthand for Pointed Functor -- in the same way that Applicative isn't called ApplicativeFunctor, even though that's what it is. So if it doesn't work for Bloom filters, the reason is that Bloom filters aren't pointed functors. *That said*, I actually have nothing at all against splitting the 'a - f a' method out into a separate class if you think it's useful, whether you call it Pointed or something else. (And `class (Pointed f, Functor f) = PointedFunctor f` is sort of cute.) I'm just trying to clarify where people are probably coming from -- those people can hopefully correct me if I'm wrong about this. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] overloaded list literals?
2010/9/6 Bulat Ziganshin bulat.zigans...@gmail.com: Hello Johannes, Monday, September 6, 2010, 2:23:35 PM, you wrote: so how about using list syntax ( [], : ) for anything list-like (e.g., Data.Sequence)? i'vwe found my own proposal of such type: http://www.mail-archive.com/haskell-cafe@haskell.org/msg15656.html Will Data.Map with its' empty, insert, findMin, etc, methods conform to your proposed type? I don't think so and I thought twice. ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] overloaded list literals?
Hello Serguey, Monday, September 6, 2010, 7:57:46 PM, you wrote: http://www.mail-archive.com/haskell-cafe@haskell.org/msg15656.html Will Data.Map with its' empty, insert, findMin, etc, methods conform to your proposed type? but Data.Map isn't sequential container. instead, it maps arbitrary keys to values -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ 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 - HTML vs. XHTML
On 6 September 2010 17:11, Mark Lentczner ma...@glyphic.com wrote: On Sep 6, 2010, at 2:40 AM, Henning Thielemann wrote: ... focusing on a small set of assumed popular browsers ... I didn't want to assume either. I ran a survey of the Haskell community and got over a 150 responses. On Sep 6, 2010, at 2:40 AM, Henning Thielemann wrote: and complying to their quirks is the wrong way. I believe the only sop to browser quirks in the current Haddock output are three lines of CSS that came from YUI 3: CSS Fonts [2] to achieve consistent font sizing in IE. These are well researched and minimal. Speaking as someone who worked at a company where we had to write 100% valid XHTML and CSS for *non-trival* designs (groans at the recollection), generally for fairly simple documents you can write standard compliant web pages with (X)HTML/CSS/JavaScript and it will render the same on Firefox/Chrome/Safari/Opera/IE8. It will probably work but look less fancy on IE6 if it's simple. If other browsers don't render correctly, that's not your problem. Regarding font sizing, you shouldn't really have to care about the size of the font. If your page renders differently on different browsers due to different font settings, that's because the user/browser chose that font set. Why do you care about consistent font sizes? Personally I'm pragmatic, I don't care about W3C validation, I do care about standards and accessibility. If your page is semantic, usable/accessible across the major browsers then you've done a great job and W3C validation is just a pat on the back. I think it's a matter of priorities. If we're going to appeal to authority, Google see it fit to start using HTML5 straight away (and they really care about validity) and (I was told at the Zurich Google offices by someone who works on YouTube) that we have no business sending XHTML to web browsers. But I don't see the particular mark-up as a Big Deal like others do, when (as I demonstrate below) there are more important issues to deal with that most people don't get right. As I did the work on Haddock, I tested the results on five browser/os combinations on my own machines, and about 30 browser/os combinations via browsershots[1]. FWIW there's a great web site that provides screenshots of IE immediately: http://ipinfo.info/netrenderer/ Don't waste your time on obscure browsers. You have better things to be doing. There were a few times where I tried something (usually a choice of markup and CSS) that looked nice in WebKit browsers (Safari and Chrome), but didn't work in Firefox or others. In those cases I retreated to other approaches. A notable example is the Portability box in the upper right. I wanted that to be a dl list, and could get it to style nicely in all browsers except Firefox on Linux! I retreated to a table in that case. Since both the thing I tried and the result were valid markup and CSS, I'm hoping you won't consider this a major concession to quirks. I'd like to see such cases of inconsistency between Webkit and Firefox (on Linux), I can help out if you're having trouble. You want to do the portability box as a definition list? For semantic meaning and search engines, there should be one h1 in the page, many h2's, and subheadings, etc. A really easy way to check your site's quality as a structured document is by rendering it without CSS or JavaScript, because it can make you aware of problems immediately: http://i.imgur.com/7ksCW.png There's no h1, what's the title of this page? The h2s have been written as h1's, and the contents, title and description aren't headings at all. The portability table is done with tds (table *data*) with no th's (table *heading*) and there's no actual description for the table. Headings are useful for navigating the document -- this is how blind people work in a browser, they get a list of headings and tab through it quickly (I have a reference study for this, I'll find it if you're interested). Just think about what are the main points of this document and the way to code it comes naturally. Like I said, you're priority has been cross-platform and validation but basic things like semantic document structure have been overlooked. Anyway, I think you're doing a sterling job and you seem to really care about doing it right, good job! It looks really nice, gives a professional sheen to Haskell's documentation. I know you need to build up a thick skin to deal with all the bikeshed-like criticism that always seems to crop up when web sites are discussed. Don't worry about my criticisms, I'm constructive about it! If you care about this stuff then I'll put my money where my mouth is and send some patches to address whatever I think could be improved, you don't have to lift a finger. If you're not really bothered then disregard all my above comments and just imagine I said awesome design, good job! ___ Haskell-Cafe mailing list
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
Good work Dan! Would you be interested in providing a build option that replaces the OpenSSL dependency with something more stand-alone? Or does ossl perform a significant part of the TLS protocol work for you (vs just being used for algorithms)? Anyone impatient for the midnight haddocking can see the docs here: http://web.cecs.pdx.edu/~dubuisst/secure-sockets-1.0/html/ Cheers, Thomas On Sun, Sep 5, 2010 at 10:26 PM, David Anderson d...@natulte.net wrote: Hi, I'm happy to announce the first release of secure-sockets, a library which aims to simplify the task of communicating securely between two authenticated peers. -- What it is The API mimicks that of Network.Socket, and introduces the additional notion of peer identity, which is distinct from the endpoint address (host and port). Connections can only be established between two peers who know and expect to be communicating with each other. Transport security is implicitly taken care of: an established Network.Secure.Connection implies that each end of the connection successfully authenticated to the other, and that they have setup strong encryption for your data. -- What it isn't The library leans towards the zero configuration end of the spectrum, and basically Just Works. This means that if you know exactly what you want and need for the cipher, authentication algorithm, key type and length, key exchange protocol, HMAC algorithm, rekeying intervals, random number source... Then secure-sockets is not for you. If on the other hand you just want to replace your current cleartext cipher and faith-based authentication code with something that gives you a good chance of being secure (see caveats in docs), without diving into the rich madness that is full blown SSL, then you might want to take a look. This library assumes that both ends of a connection are using it. The goal of secure-sockets is not to allow you to connect to any SSL-enabled server, or to speak a particular standard flavor of authentication protocol. Internally, secure-sockets uses SSL to achieve its goals, so you might get lucky if you do it just right, but that is an implementation detail. The library is designed to help you easily secure communications between two programs whose implementation you control, not between you and anything out there. -- Links Homepage: http://secure-hs.googlecode.com/ Hackage page: http://hackage.haskell.org/package/secure-sockets Bug tracker: http://code.google.com/p/secure-hs/issues/list Code repository: https://secure-hs.googlecode.com/hg -- Thanks I'd like to thank my employer, Google. Not only did they not get mad at the idea that I might want to hack on Haskell during working hours (as my 20% project), they also made it very painless for me to open source this code when the time came. -- Questions? Questions, comments, suggestions and patches can be filed in the issue tracker, emailed directly to me, or thrown out on haskell-cafe. Hope you find this code useful! - Dave ___ 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[4]: [Haskell-cafe] overloaded list literals?
Hello Serguey, Monday, September 6, 2010, 8:16:03 PM, you wrote: Basically, you - and others, - propose to add another class isomorphic to already present lists. I think, most benefits of that class can be achieved by using list conversion and RULE pragma. what i propose should allow to convert algorithm dealing with strings into algorithm dealing with ByteStrings, simply by changing import statement it's a cute goal - keep Haskell strings easy of use but add ByteString performance -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] overloaded list literals?
On Mon, Sep 6, 2010 at 12:47 PM, Neil Brown nc...@kent.ac.uk wrote: On 06/09/10 11:23, Johannes Waldmann wrote: We have overloaded numerical literals (Num.fromInteger) and we can overload string literals (IsString.fromString), so how about using list syntax ( [], : ) for anything list-like (e.g., Data.Sequence)? I would have thought you have two obvious choices for the type-class (things like folding are irrelevant to overloading list literals): class IsList f where fromList :: [a] - f a or: class IsList f where cons :: a - f a - f a empty :: f a I'd go for the first, as I'd imagine you are only overloading the [a,b,c] form, not the a:b:c:[] form, and the first reflects this better. Both of these could be used to convert a list literal into a list-like type (e.g. Sequence). But neither of them would be useful for sets or maps, because the classes lack an Ord constraint on the type a -- maybe this makes overloaded list literals fairly limited in utility. I endorse the idea of a class along the lines of the first example. That takes care of convenient syntax for literals; view patterns can give you the other end, pattern matching*. The fact that this doesn't work for Sets and the like is indeed troublesome, but I think you can solve it: class IsListLikeThingamabob f where type ElemOf f fromList :: [ElemOf f] - f then you can do: instance Ord a = IsListLikeThingamabob (S.Set a) where type ElemOf (S.Set a) = a fromList = S.fromList and that way you can also use it for *-kinded types like ByteString, if for whatever reason you might want to. I think the aim here should be just to gain access to the convenient list syntax for use with other types -- a fully generalized interface for collections of all shapes and sizes is out of scope, and _hard_. (But Ivan Miljenovic seems to be working on it.) * Especially if, as discussed on the wiki[1], view patterns also get upgraded to hook into a type class: data View a where type ViewOf a view :: a - ViewOf a where defining an instance would allow you to omit the name of the viewing function, defaulting to 'view' instead. So if you define ViewOf (MyContainer a) as [a], you could match using: foo (- []) = something foo (- x:xs) = something else (I believe the main holdup wrt this is indecision over whether to use a plain MPTC, or a fundep / associated type in one direction, or one in the other. The version above looks clearly superior to me, but I don't want to derail the thread further. If someone else does, fork it. :) [1] http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns Thanks, Neil. ___ 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] ANNOUNCE: secure-sockets version 1.0
On Mon, Sep 6, 2010 at 9:16 AM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: Good work Dan! Sorry! David. Good work David. Not sure where Dan came from. Would you be interested in providing a build option that replaces the OpenSSL dependency with something more stand-alone? Or does ossl perform a significant part of the TLS protocol work for you (vs just being used for algorithms)? Anyone impatient for the midnight haddocking can see the docs here: http://web.cecs.pdx.edu/~dubuisst/secure-sockets-1.0/html/ Cheers, Thomas On Sun, Sep 5, 2010 at 10:26 PM, David Anderson d...@natulte.net wrote: Hi, I'm happy to announce the first release of secure-sockets, a library which aims to simplify the task of communicating securely between two authenticated peers. -- What it is The API mimicks that of Network.Socket, and introduces the additional notion of peer identity, which is distinct from the endpoint address (host and port). Connections can only be established between two peers who know and expect to be communicating with each other. Transport security is implicitly taken care of: an established Network.Secure.Connection implies that each end of the connection successfully authenticated to the other, and that they have setup strong encryption for your data. -- What it isn't The library leans towards the zero configuration end of the spectrum, and basically Just Works. This means that if you know exactly what you want and need for the cipher, authentication algorithm, key type and length, key exchange protocol, HMAC algorithm, rekeying intervals, random number source... Then secure-sockets is not for you. If on the other hand you just want to replace your current cleartext cipher and faith-based authentication code with something that gives you a good chance of being secure (see caveats in docs), without diving into the rich madness that is full blown SSL, then you might want to take a look. This library assumes that both ends of a connection are using it. The goal of secure-sockets is not to allow you to connect to any SSL-enabled server, or to speak a particular standard flavor of authentication protocol. Internally, secure-sockets uses SSL to achieve its goals, so you might get lucky if you do it just right, but that is an implementation detail. The library is designed to help you easily secure communications between two programs whose implementation you control, not between you and anything out there. -- Links Homepage: http://secure-hs.googlecode.com/ Hackage page: http://hackage.haskell.org/package/secure-sockets Bug tracker: http://code.google.com/p/secure-hs/issues/list Code repository: https://secure-hs.googlecode.com/hg -- Thanks I'd like to thank my employer, Google. Not only did they not get mad at the idea that I might want to hack on Haskell during working hours (as my 20% project), they also made it very painless for me to open source this code when the time came. -- Questions? Questions, comments, suggestions and patches can be filed in the issue tracker, emailed directly to me, or thrown out on haskell-cafe. Hope you find this code useful! - Dave ___ 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 Sep 2, 2010, at 11:24 AM, Yuras Shumovich wrote: Is it possible to switch back from frame version to non frame version? The Frames button disappears in frame mode... I usually just right-click on the main page and select Open frame in new window I could have made the Frames button become Unframe... do people think that's worth it? I was worried about clutter, but can add it in easy enough if folks think it makes sense. Also style changing works only inside the main frame. True - the Haddock team suspected that style changing was something people would play with a bit, pick a style they liked and leave it. Once you refresh the page - all the panels will change to the style you picked and continue to stay that way. I thought of adding logic to the Style menu to do this when in frames mode just didn't make the cut before we wanted to ship. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] container-classes (was: Restricted type classes)
I'd like to make one more argument in favor of my preference for more splitting of type classes. IMO it's beneficial to split up classes to minimize unnecessary dependencies. That is, while e.g. Monoid is very useful for containers, many container methods won't need it, e.g. elem or filter. When you divide the type classes so only what's necessary is required, more data structures will be able to meet those criteria, which in turn makes the class more generally useful. As an example, I have an extension to iteratee which uses raw buffers for holding data. This allows it to operate in truly constant memory (only one allocation, deallocated when it's finished), which has resulted in performance benefits. Unfortunately there is not a good Monoid instance for this type because appending buffers is not possible. By introducing the NullPoint class (equivalent to mempty of Monoid) in iteratee, my raw buffer extension is able to re-use several iteratee functions which it would not be able to if I had require Monoid instead of NullPoint. I think I've made my arguments as well as I can, so I'm going to be quiet now unless something new comes up. Cheers, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Operator precedence
Is there a handy list of operators and their precedence somewhere? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] overloaded list literals?
Bulat, btw, i also had proposal to automatically convert typeclasses used in type declarations into constraints, [...] Together with proposals i mentioned previously, it will allow to treat existing code dealing with lists/strings as generic code working with any sequential container type I see. That's a nice proposal, but somehow I'm a bit worried about readability of code. IMHO, readability is still one of Haskell's main assets and I wouldn't like to see it degrade (further). Cheers, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Operator precedence
Take a look to the Haskell Report: http://www.haskell.org/onlinereport/haskell2010/haskellch9.html#x16-1710009 -- Daniel Díaz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Operator precedence
Thanks, Daniel. This be all of them? Michael infixr 9 . infixr 8 ^, ^^, ⋆⋆ infixl 7 ⋆, /, ‘quot‘, ‘rem‘, ‘div‘, ‘mod‘ infixl 6 +, - -- The (:) operator is built-in syntax, and cannot legally be given -- a fixity declaration; but its fixity is given by: -- infixr 5 : infix 4 ==, /=, , =, =, infixr 3 infixr 2 || infixl 1 , = infixr 1 = infixr 0 $, $!, ‘seq‘ --- On Mon, 9/6/10, Daniel Díaz lazy.dd...@gmail.com wrote: From: Daniel Díaz lazy.dd...@gmail.com Subject: Re: [Haskell-cafe] Operator precedence To: michael rice nowg...@yahoo.com, haskell-cafe@haskell.org Date: Monday, September 6, 2010, 1:06 PM Take a look to the Haskell Report: http://www.haskell.org/onlinereport/haskell2010/haskellch9.html#x16-1710009 -- Daniel Díaz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Operator precedence
Those are all operators in Prelude. See a concrete library for their operator precedences. -- Daniel Díaz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] circular imports
Lately I've been spending more and more time trying to figure out how to resolve circular import problems. I add some new data type and suddenly someone has a new dependency and now the modules are circular. The usual solution is to move the mutually dependent definitions into the same module, but sometimes those threaten to drag in a whole zoo of other dependencies, *all* of which would have to go into the same module, which is already quite large anyway. Of course this requires lots of thought and possibly refactoring and is a big pain all around. I feel like the circular imports problem is worse in haskell than other languages. Maybe because there is a tendency to centralize all state, since you need to define it along with your state monad. But the state monad module must be one of the lower level ones, since all modules that use it must import it. However, the tendency for bits of typed data to migrate into the state means it's easy for it to eventually want to import one of its importers. And the state monad module gets larger and larger (the largest modules in my system are those that define state monads: 1186 lines, 706 lines, 1156 lines---the rest tend to be 100--300 lines). I haven't really had this problem in other languages. Maybe it's because I just don't write very big programs in other languages, or maybe because some other languages are dynamically typed and don't make you import a module to use its types, or maybe because some other languages support forward declaration (actually, ghc haskell does support a form of forward declaration in hs-boot files). I have a few techniques to get out: - Replace Things with ThingIds which have no big dependencies, and can then be looked up in a Map later. This replaces direct access with lookup and thows some extra Maybes in there, which is not very nice. - Cleverly use type variables to try to factor out the problematic type. Then I can stitch the data structure back together at a higher level with a type alias. This is sort of complicated and awkward. - Move the declarations that must be moved to the low level module, re-export them from the module that defines their (smart) constructors, and pretend like they belong to that module. This works well when it can work, but makes the code awkward to navigate and doesn't let you hide their implementation unless you give up and move the rest of the code in as well. - Just use an hs-boot. The main problem I've noticed with this so far is that you wind up with a lot of recompilation, since ghc always seems to want to start with the boot files and then recompile the loop. This makes ghci use a little more annoying. Actually, sometimes :r simply reloads the changed module, but sometimes it wants to start again at the hs-boots and recompiles a whole pile, I'm not sure what makes the difference. Probably making the loop as small as possible would help here. Is this a problem others have noticed? Any other ideas or solutions? thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
On Mon, Sep 6, 2010 at 7:51 AM, John Lato jwl...@gmail.com wrote: On Sun, Sep 5, 2010 at 7:18 PM, David Menendez d...@zednenem.com wrote: On Sun, Sep 5, 2010 at 8:40 AM, John Lato jwl...@gmail.com wrote: On Sat, Sep 4, 2010 at 12:34 PM, David Menendez d...@zednenem.com wrote: On Fri, Sep 3, 2010 at 8:23 AM, John Lato jwl...@gmail.com wrote: +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? Having Pointed is categorically the right thing to do, which is why I argue for its inclusion. Why is it categorically the right thing to do? Because it's the proper abstraction underlying Applicative and Monad, as far as I understand category theory. What makes it the proper abstraction? Applicative Functors have three parts: the functor, pure, and *, along with some equations they need to satisfy. We know Functor by itself is useful, but what makes Functor+pure better than Functor+* or pure+* or any other subset? The fact that it has a name doesn't make it useful for programming; category theory has names for all sorts of things that don't come up very often. For that matter, can you even describe what pure is intended to do without reference to * or join? You can say that it's a natural transformation from Id to f, but so is \x - [x,x]. You can say it contains one copy of the argument, but that doesn't work for the Const functor or the infinite stream functor, among others. I notice no one has given any algorithms that operate on arbitrary pointed functors. When Conor McBride was promoting the use of Applicative (then called Idiom), he provided several instances and algorithms showing that it was a useful generalization of Monad, and it still took several years and a few papers[1] before Applicative found its way into the standard library. In other words, we didn't add Applicative and then discover Traversable later. Traversable was a big part of the argument for why Applicative is useful. I take this in favor of my point. Applicative wasn't considered useful, so it wasn't included. Then Conor McBride shows that it is useful, but at that point it was too late and now we're stuck with pure, return, ap, liftA2, liftM2, etc. I think that has more to do with Haskell 98 compatibility. We broke Category out of Arrow not too long ago. Furthermore, you didn't address my point: Applicative is *useful*. We have algorithms that are parameterized by arbitrary applicative functors. We have multiple examples of useful non-monad applicative functors. What are pointed functors good for? -- 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] Operator precedence
A concrete library? I'm playing around with Data.Bits. It has .. and .|. which I assume are functions (rather than operators) because I don't see and infix statement for them. Correct? Michael --- On Mon, 9/6/10, Daniel Díaz lazy.dd...@gmail.com wrote: From: Daniel Díaz lazy.dd...@gmail.com Subject: Re: [Haskell-cafe] Operator precedence To: michael rice nowg...@yahoo.com, haskell-cafe@haskell.org Date: Monday, September 6, 2010, 1:17 PM Those are all operators in Prelude. See a concrete library for their operator precedences. -- Daniel Díaz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] circular imports
On Mon, 6 Sep 2010, Evan Laforge wrote: I have a few techniques to get out: - Replace Things with ThingIds which have no big dependencies, and can then be looked up in a Map later. This replaces direct access with lookup and thows some extra Maybes in there, which is not very nice. - Cleverly use type variables to try to factor out the problematic type. Then I can stitch the data structure back together at a higher level with a type alias. This is sort of complicated and awkward. That's what I typically make. It was only once, where I could not easily decide which datatype to make the parameter of the other one. - Move the declarations that must be moved to the low level module, re-export them from the module that defines their (smart) constructors, and pretend like they belong to that module. This works well when it can work, but makes the code awkward to navigate and doesn't let you hide their implementation unless you give up and move the rest of the code in as well. I often need Private modules anyway for package-wide definitions. Then I define the type in the Private module and export it only from the corresponding public module. Unfortunately, Haddock does not play nicely with it. I would like to tell Haddock to treat the public module as the one that defines the type. Is this a problem others have noticed? Any other ideas or solutions? Unfortunately no more ideas, but you may add more thoughts to http://haskell.org/haskellwiki/Mutually_recursive_modules#Resolve_mutual_recursion ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] circular imports
Excerpts from Evan Laforge's message of Mon Sep 06 13:30:43 -0400 2010: I feel like the circular imports problem is worse in haskell than other languages. Maybe because there is a tendency to centralize all state, since you need to define it along with your state monad. But the state monad module must be one of the lower level ones, since all modules that use it must import it. However, the tendency for bits of typed data to migrate into the state means it's easy for it to eventually want to import one of its importers. And the state monad module gets larger and larger (the largest modules in my system are those that define state monads: 1186 lines, 706 lines, 1156 lines---the rest tend to be 100--300 lines). I have used hs-boot files to this effect. I separated data and functionality, and typeclasses, which must be in the same module as data or are considered orphaned, get definitions via a circular import. Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Grempa 0.1.0, Embedded grammar DSL and LALR parser generator
Hello everyone,
I'm pleased to announce the first release of Grempa:
A library for expressing programming language grammars in a form similar
to BNF, which is extended with the semantic actions to take when
a production has been parsed. The grammars are typed and are to be be
used
with the LALR(1) parser generator, also part of the library, which can
generate a parser for the language either at compile time using Template
Haskell, producing fast parsers with no initial runtime overhead, or
dynamically, which has the initial overhead of generating the parser,
but
can be used for example when the grammar depends on an input.
Here is a small example (from Ex1 in the examples directory) of what a
grammar
may look like:
data E = Plus E E
| Times E E
| Var
| ...
expr :: Grammar Char E
expr = do
rec
e - rule [ Plus @ e # '+' # t
, id@ t
]
t - rule [ Times @ t # '*' # f
, id@ f
]
f - rule [ id@ '(' # e # ')'
, Var @ 'x'
]
return e
The corresponding BNF grammar is the following:
E ::= E + T
| T
T ::= T * F
| F
F ::= ( E )
| x
Generating a parser from the grammar is simple:
parseExpr :: Parser Char E
parseExpr = $(mkStaticParser expr [|expr|])
There are a few other examples in the examples directory of the package,
most
notably a grammar and parser for a simple functional language similar to
Haskell.
It is possible to generate random input strings and their expected outputs
for grammars written using Grempa which makes it possible to test the
generated
parsers with QuickCheck.
The package and documentation (should be up soon) can be found here:
http://hackage.haskell.org/package/Grempa-0.1.0
Please get in touch with me if you have any comments, issues, questions, bug
reports or would like to contribute to the project. I would love to get some
more people involved in the project, as there are many areas of the library
that
could be improved.
Thanks to Daniel Gustafsson and everyone else at Chalmers Uni for valuable
input and getting me into Haskell (respectively).
Regards,
Olle Fredriksson
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Operator precedence
Hello michael, Monday, September 6, 2010, 9:00:32 PM, you wrote: Is there a handy list of operators and their precedence somewhere? unlike most languages, operators are user-definable in haskell. so there is no comprehensive list any function with two arguments van be used as operator: a `min` b any operator may be defined or used as a function: () a b = ... main = print (() True False) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Operator precedence
On Mon, Sep 6, 2010 at 1:37 PM, michael rice nowg...@yahoo.com wrote: A concrete library? I'm playing around with Data.Bits. It has .. and .|. which I assume are functions (rather than operators) because I don't see and infix statement for them. Correct? .|. and .. are operators because they are made from symbol characters. Operators default to infixl 9 unless specified otherwise, so no infix declaration is needed. However, Data.Bits does have infix declarations for .. and .|. : infixl 8 `shift`, `rotate`, `shiftL`, `shiftR`, `rotateL`, `rotateR` infixl 7 .. infixl 6 `xor` infixl 5 .|. If you want to check the fixity of an operator, use :info in GHCi. Prelude Data.Bits :i .|. class (Num a) = Bits a where ... (.|.) :: a - a - a ... -- Defined in Data.Bits infixl 5 .|. -- 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] Operator precedence
Hi David, You're right, I keep forgetting to look at the source code. And I wasn't aware of the info (:i) command. Should come in handy in the future. Michael --- On Mon, 9/6/10, David Menendez d...@zednenem.com wrote: From: David Menendez d...@zednenem.com Subject: Re: [Haskell-cafe] Operator precedence To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org, Daniel Díaz lazy.dd...@gmail.com Date: Monday, September 6, 2010, 1:50 PM On Mon, Sep 6, 2010 at 1:37 PM, michael rice nowg...@yahoo.com wrote: A concrete library? I'm playing around with Data.Bits. It has .. and .|. which I assume are functions (rather than operators) because I don't see and infix statement for them. Correct? .|. and .. are operators because they are made from symbol characters. Operators default to infixl 9 unless specified otherwise, so no infix declaration is needed. However, Data.Bits does have infix declarations for .. and .|. : infixl 8 `shift`, `rotate`, `shiftL`, `shiftR`, `rotateL`, `rotateR` infixl 7 .. infixl 6 `xor` infixl 5 .|. If you want to check the fixity of an operator, use :info in GHCi. Prelude Data.Bits :i .|. class (Num a) = Bits a where ... (.|.) :: a - a - a ... -- Defined in Data.Bits infixl 5 .|. -- 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] Operator precedence
El Lun, 6 de Septiembre de 2010, 7:50 pm, David Menendez escribió: Operators default to infixl 9 unless specified otherwise, so no infix declaration is needed. Why there is a default infix? Why it is 9? -- Daniel Díaz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: countable-0.1
On Mon, 2010-09-06 at 03:54 -0700, Ashley Yakeley wrote: countable: Countable, Searchable, Finite, Empty classes. class Countable, for countable types class AtLeastOneCountable, for countable types that have at least one value class InfiniteCountable, for infinite countable types class Searchable, for types that can be searched over class Finite, for finite types class Empty, for empty types data Nothing, an empty type Also includes these orphan instances: instance (Searchable a,Eq b) = Eq (a - b) instance (Finite a) = Foldable ((-) a) instance (Finite a) = Traversable ((-) a) instance (Show a,Finite a,Show b) = Show (a - b) It turns out Searchable includes some infinite types. Specifically, countable implements this: instance (Countable c,Searchable s) = Searchable (c - s) using the algorithm described here: http://math.andrej.com/2007/09/28/seemingly-impossible-functional-programs/ I would welcome improvements. http://hackage.haskell.org/package/countable-0.1 cabal install countable darcs get http://code.haskell.org/countable/ See also this thread: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/73275 Hmm. 1. Code formatting is very C#-like. At least for me it is hard to read the code that way (it IS matter of preference however) 2. countMaybeNext seems to need documentation. If I understand it correctly: countMaybeNext Nothing = 'minimalValue' countMaybeNext (Just x) = x + 1 Wouldn't be split it to: countNext :: a - Maybe a initial :: Maybe a 3. 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
[Haskell-cafe] Re: overloaded list literals?
On Mon, 2010-09-06 at 10:23 +, Johannes Waldmann wrote: We have overloaded numerical literals (Num.fromInteger) and we can overload string literals (IsString.fromString), so how about using list syntax ( [], : ) for anything list-like (e.g., Data.Sequence)? Of course some minor details would need to be worked out, like what methods should go in the hypothetical class IsList (is is Foldable?) and what to do about pattern matching (perhaps we don't need it?) Foldable is not necessary a good choice. Neither ByteString nor Text is Foldable. It would make hard to write methods like: checkMagicKey :: ByteString - Bool checkMagicKey (0x85:0x86:_) = True checkMagicKey _ = False or checkFoo :: Text - Bool checkFoo Foo = True checkFoo _ = False IIRC there was a time when list comprehension would actually mean monad comprehension (when there was no do notation) but that's not what I'm getting at here. Or is it? Do we have a Haskell museum of ideas from the past? Best - J.W. I guess the laziness and view patterns are sufficient: checkMagicKey :: ByteString - Bool checkMagicKey (unpack - 0x85:0x86:_) = True checkMagicKey _ = False checkFoo :: Text - Bool checkFoo (unpack - Foo) = True checkFoo _ = False The problems: - In teaching list are useful because they are simple. View patterns are not. Even if view patterns were standard it could be considered too complicated to teach. - They introduce nothing more then is already achievable as it is possible to write checkFoo x = case unpack x of Foo - ... _ - ... or checkFoo x | unpack x == Foo = ... | otherwise = ... - I may be wrong but they require the recomputation on each call of unpack I guess that maybe active patterns should be considered to be imported from F#. I'm not quite sure about syntax and maybe they are too logic like. PS. data FooBar a = Foo | Bar deriving Show class IsString (FooBar Char) where toString _ = Foo class IsList FooBar where toList _ = Bar show (1234 :: FooBar Char) == ??? 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] Operator precedence
On Mon, Sep 6, 2010 at 2:21 PM, Daniel Díaz danield...@asofilak.es wrote: El Lun, 6 de Septiembre de 2010, 7:50 pm, David Menendez escribió: Operators default to infixl 9 unless specified otherwise, so no infix declaration is needed. Why there is a default infix? Why it is 9? That's what the Haskell Report says: Any operator lacking a fixity declaration is assumed to be infixl 9 (section 4.4.2). Any function with at least two arguments can be used as an operator, so there has to be a default. Presumably, infixl 9 was considered the least surprising. -- 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] Update gtk2hs!
Hi all, I'm working on update gtk2hs APIs. 'gio' has update to newest version, all patches has push to repo, i need more test before release gio-0.12.0 About `gtk` packages, i have push some gtk+-2.18/gtk+-2.20 patches to repo but not all, i plan finish all APIs before release gtk-0.12.0. If anyone interested this, welcome to join! :) We can release gtk-0.12.0 quicker if more people join us. GTK+-2.18 new modules have *finish* at http://www2.in.tum.de/~simona/gtk2hs-2.18/gtk/Graphics/UI/Gtk/ Because have some bugs in those code (my fault), you need review every APIs before send patch, but it's much simple than build those module by yourself. Below are missing modules in gtk+-2.18: gtk/Graphics/UI/Gtk/Printing/PageSetup.chs gtk/Graphics/UI/Gtk/Printing/PaperSize.chs gtk/Graphics/UI/Gtk/Printing/PrintContext.chs gtk/Graphics/UI/Gtk/Printing/PrintOperation.chs gtk/Graphics/UI/Gtk/Printing/PrintOperationPreview.chs gtk/Graphics/UI/Gtk/Printing/PrintSettings.chs gtk/Graphics/UI/Gtk/Recent/RecentChooser.chs gtk/Graphics/UI/Gtk/Recent/RecentChooserDialog.chs gtk/Graphics/UI/Gtk/Recent/RecentChooserMenu.chs gtk/Graphics/UI/Gtk/Recent/RecentChooserWidget.chs gtk/Graphics/UI/Gtk/Recent/RecentFilter.chs gtk/Graphics/UI/Gtk/Recent/RecentInfo.chs gtk/Graphics/UI/Gtk/Recent/RecentManager.chs gtk/Graphics/UI/Gtk/Special/HRuler.chs gtk/Graphics/UI/Gtk/Special/Ruler.chs gtk/Graphics/UI/Gtk/Special/VRuler.chs gtk/Graphics/UI/Gtk/Selectors/HSV.chs gtk/Graphics/UI/Gtk/ActionMenuToolbar/Action.chs gtk/Graphics/UI/Gtk/ActionMenuToolbar/ActionGroup.chs gtk/Graphics/UI/Gtk/ActionMenuToolbar/Activatable.chs gtk/Graphics/UI/Gtk/ActionMenuToolbar/RadioAction.chs gtk/Graphics/UI/Gtk/ActionMenuToolbar/RecentAction.chs gtk/Graphics/UI/Gtk/ActionMenuToolbar/ToggleAction.chs gtk/Graphics/UI/Gtk/ActionMenuToolbar/UIManager.chs gtk/Graphics/UI/Gtk/Buttons/gtk/Graphics/UI/Gtk/LinkButton.chs gtk/Graphics/UI/Gtk/Buttons/gtk/Graphics/UI/Gtk/ScaleButton.chs gtk/Graphics/UI/Gtk/Buttons/gtk/Graphics/UI/Gtk/VolumeButton.chs gtk/Graphics/UI/Gtk/Display/InfoBar.chs gtk/Graphics/UI/Gtk/Entry/EntryBuffer.chs gtk/Graphics/UI/Gtk/Gdk/AppLaunchContext.chs gtk/Graphics/UI/Gtk/Gdk/Colormap.chs gtk/Graphics/UI/Gtk/Gdk/Device.chs gtk/Graphics/UI/Gtk/Gdk/DisplayManager.chs gtk/Graphics/UI/Gtk/Gdk/Keymap.chs gtk/Graphics/UI/Gtk/Gdk/PixbufLoader.chs gtk/Graphics/UI/Gtk/Gdk/Visual.chs gtk/Graphics/UI/Gtk/General/AccelGroup.chs gtk/Graphics/UI/Gtk/General/AccelMap.chs gtk/Graphics/UI/Gtk/General/Binding.chs gtk/Graphics/UI/Gtk/General/IconInfo.chs gtk/Graphics/UI/Gtk/General/Paint.chs gtk/Graphics/UI/Gtk/MenuComboToolbar/Item.chs gtk/Graphics/UI/Gtk/MenuComboToolbar/ToolShell.chs gtk/Graphics/UI/Gtk/Misc/IMContextSimple.chs gtk/Graphics/UI/Gtk/ModelView/CellEditable.chs gtk/Graphics/UI/Gtk/ModelView/CellRendererAccel.chs gtk/Graphics/UI/Gtk/ModelView/CellRendererSpin.chs GTK+2.20 just below APIs haven't finish: Index of new symbols in 2.20 C GtkCellEditable:editing-canceled, object property in GtkCellEditable GtkCellRendererSpinner:pulse, object property in GtkCellRendererSpinner GtkCellRendererSpinner:size, object property in GtkCellRendererSpinner gtk_cell_renderer_spinner_new, function in GtkCellRendererSpinner O gtk_offscreen_window_get_pixbuf, function in GtkOffscreenWindow gtk_offscreen_window_get_pixmap, function in GtkOffscreenWindow gtk_offscreen_window_new, function in GtkOffscreenWindow P gtk_paint_spinner, function in GtkStyle gtk_printer_get_hard_margins, function in GtkPrinter gtk_print_context_get_hard_margins, function in GtkPrintContext T GtkToolPalette::set-scroll-adjustments, object signal in GtkToolPalette GtkToolPalette:exclusive, object property in GtkToolPalette GtkToolPalette:expand, object property in GtkToolPalette GtkToolPalette:icon-size, object property in GtkToolPalette GtkToolPalette:icon-size-set, object property in GtkToolPalette GtkToolPalette:toolbar-style, object property in GtkToolPalette gtk_tool_item_get_ellipsize_mode, function in GtkToolItem gtk_tool_item_get_text_alignment, function in GtkToolItem gtk_tool_item_get_text_orientation, function in GtkToolItem gtk_tool_item_get_text_size_group, function in GtkToolItem gtk_tool_item_group_get_collapsed, function in GtkToolItemGroup gtk_tool_item_group_get_drop_item, function in GtkToolItemGroup gtk_tool_item_group_get_ellipsize, function in GtkToolItemGroup gtk_tool_item_group_get_header_relief, function in GtkToolItemGroup gtk_tool_item_group_get_item_position, function in GtkToolItemGroup gtk_tool_item_group_get_label, function in GtkToolItemGroup gtk_tool_item_group_get_label_widget, function in GtkToolItemGroup gtk_tool_item_group_get_nth_item, function in GtkToolItemGroup gtk_tool_item_group_get_n_items, function in GtkToolItemGroup gtk_tool_item_group_insert, function in GtkToolItemGroup gtk_tool_item_group_new, function in GtkToolItemGroup gtk_tool_item_group_set_collapsed, function in
Re: [Haskell-cafe] Re: overloaded list literals?
On Mon, Sep 6, 2010 at 8:52 PM, Maciej Piechotka uzytkown...@gmail.com wrote: PS. data FooBar a = Foo | Bar deriving Show class IsString (FooBar Char) where toString _ = Foo class IsList FooBar where toList _ = Bar show (1234 :: FooBar Char) == ??? Foo -- 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] Restricted type classes
On Mon, Sep 6, 2010 at 12:33 PM, David Menendez d...@zednenem.com wrote: On Mon, Sep 6, 2010 at 7:51 AM, John Lato jwl...@gmail.com wrote: On Sun, Sep 5, 2010 at 7:18 PM, David Menendez d...@zednenem.com wrote: On Sun, Sep 5, 2010 at 8:40 AM, John Lato jwl...@gmail.com wrote: On Sat, Sep 4, 2010 at 12:34 PM, David Menendez d...@zednenem.com wrote: On Fri, Sep 3, 2010 at 8:23 AM, John Lato jwl...@gmail.com wrote: +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? Having Pointed is categorically the right thing to do, which is why I argue for its inclusion. Why is it categorically the right thing to do? Because it's the proper abstraction underlying Applicative and Monad, as far as I understand category theory. What makes it the proper abstraction? Applicative Functors have three parts: the functor, pure, and *, along with some equations they need to satisfy. We know Functor by itself is useful, but what makes Functor+pure better than Functor+* or pure+* or any other subset? The fact that it has a name doesn't make it useful for programming; category theory has names for all sorts of things that don't come up very often. I'm arguing in favor of pure by itself, not just pure+Functor. Ivan's already given one example of a structure that only meets the point criteria: a Bloom filter. Regarding Applicative Functors somewhat off-topic, you can define fmap strictly in terms of pure+*. It's interesting that they're somewhat parallel to non-applicative Functors in that the Functor instance isn't necessary, it's the pointed and * that are. Once you have those you get Functor for free. But a non-applicative functor doesn't necessarily have either. Can you give an example of a Functor that doesn't have pure? I think it's Pointed Functors which are useful; not Functor by itself. For that matter, can you even describe what pure is intended to do without reference to * or join? You can say that it's a natural transformation from Id to f, but so is \x - [x,x]. You can say it contains one copy of the argument, but that doesn't work for the Const functor or the infinite stream functor, among others. Broadly, I agree that pure should behave in a manner consistent with the Applicative or Monad instance if they exist. In the context of a collections interface though, pure should be identical to singleton, which should guide the choice of Applicative or Monad if there is one. I notice no one has given any algorithms that operate on arbitrary pointed functors. Ivan gave one useful data structure for which point by itself has meaning but Applicative doesn't. Also Point would be a useful base class for a non-empty data API (for which Monoid is unusable). When Conor McBride was promoting the use of Applicative (then called Idiom), he provided several instances and algorithms showing that it was a useful generalization of Monad, and it still took several years and a few papers[1] before Applicative found its way into the standard library. In other words, we didn't add Applicative and then discover Traversable later. Traversable was a big part of the argument for why Applicative is useful. I take this in favor of my point. Applicative wasn't considered useful, so it wasn't included. Then Conor McBride shows that it is useful, but at that point it was too late and now we're stuck with pure, return, ap, liftA2, liftM2, etc. I think that has more to do with Haskell 98 compatibility. We broke Category out of Arrow not too long ago. What was Category doing in Arrow to begin with? Wouldn't it have been easier if they had been separate from the start? Why do you think we should do the same thing now? Furthermore, you didn't address my point: Applicative is *useful*. We have algorithms that are parameterized by arbitrary applicative functors. We have multiple examples of useful non-monad applicative functors. What are pointed functors good for? Again, I don't care so much for pointed functors as for Pointed, and I've given two examples of where it would be useful. What's wrong with breaking Pointed off? All it requires is one instance with one method which you would have written anyway. That's one extra LOC, and if you base Monad and Applicative off of it there's zero change. Also a clear separation of concerns is better than conflating meanings together. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
On Mon, Sep 6, 2010 at 9:16 AM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: Good work Dan! Would you be interested in providing a build option that replaces the OpenSSL dependency with something more stand-alone? I'd be interested with breaking the dependency on OpenSSL, for various reasons: - OpenSSL's API makes it very hard to determine the purity of calls, which makes IO leak into the entire Haskell API. - The API provides basically no way of generating a valid self-signed TLS certificate. Even C programmers using the API directly have given up, and tell you to shell out to the `openssl` binary to do that. - The HsOpenSSL bindings are incomplete in various ways (notably, lack of Diffie-Hellman keying support, which forced me to use a ciphersuite that doesn't guarantee perfect forward secrecy). This I can fix by submitting patches, but it does add to the other bad stuff right now. However, dropping the OpenSSL dependency is harder than it looks: Or does ossl perform a significant part of the TLS protocol work for you (vs just being used for algorithms)? OpenSSL does all the heavy crypto lifting in my library. secure-sockets in its current implementation basically takes care of forcing the use of a single good TLS ciphersuite, ensuring that only explicitly provided certs are used for authentication (i.e. don't accept random Verisign certs), and of enforcing two-way authentication (TLS defaults to only authenticating the server, the server has to forcibly demand authentication material from the client). So, a replacement would need to be a complete replacement for TLS. I did in fact try to start with this, implementing my own simpler TLS-ish protocol, using crypto primitives directly. It took a group of crypto experts about 5 minutes to punch 3 different holes in the protocol, from leaking session key bits to sneaky replay attacks and increased risk of side-channel compromise. After talking it over with them, for all of TLS's warts, it is a terribly well designed protocol from the security standpoint, and the recommendation of my experts was basically to use it until I needed something that TLS cannot provide, at which point I should start building my own transport security protocol. So, unless there are crypto experts in the room who fancy building something better than TLS for the purposes of simple peer-to-peer security, I'm sticking with TLS for now. This gives me a choice of the three major TLS implementations: OpenSSL, GnuTLS, or Mozilla's NSS. Of those three, OpenSSL is regarded as the most widely used and battle hardened. It also happens that it's the only library with Haskell FFI bindings :-). That said, with the Haskell Crypto API stabilizing, I've been toying with the project of a pure Haskell TLS implementation, which would solve the annoying dependency issue while hanging on to a hardened protocol. However, this is also far from a simple endeavor, especially if the implementation is to be hardened against side-channel attacks, which I'm not even sure is possible in Haskell. So, to sum up: yes I'd like to ditch the OpenSSL dependency, but in the current state of the world, it seems to me that OpenSSL is the least bad choice there is. I'd love to be proven wrong through! Anyone impatient for the midnight haddocking can see the docs here: http://web.cecs.pdx.edu/~dubuisst/secure-sockets-1.0/html/ Or if you prefer the shiny new templates (upgrade your haddock!), http://natulte.net/random/secure-sockets/ . - Dave Cheers, Thomas On Sun, Sep 5, 2010 at 10:26 PM, David Anderson d...@natulte.net wrote: Hi, I'm happy to announce the first release of secure-sockets, a library which aims to simplify the task of communicating securely between two authenticated peers. -- What it is The API mimicks that of Network.Socket, and introduces the additional notion of peer identity, which is distinct from the endpoint address (host and port). Connections can only be established between two peers who know and expect to be communicating with each other. Transport security is implicitly taken care of: an established Network.Secure.Connection implies that each end of the connection successfully authenticated to the other, and that they have setup strong encryption for your data. -- What it isn't The library leans towards the zero configuration end of the spectrum, and basically Just Works. This means that if you know exactly what you want and need for the cipher, authentication algorithm, key type and length, key exchange protocol, HMAC algorithm, rekeying intervals, random number source... Then secure-sockets is not for you. If on the other hand you just want to replace your current cleartext cipher and faith-based authentication code with
Re: Re[4]: [Haskell-cafe] overloaded list literals?
2010/9/6 Bulat Ziganshin bulat.zigans...@gmail.com: Hello Serguey, Monday, September 6, 2010, 8:16:03 PM, you wrote: Basically, you - and others, - propose to add another class isomorphic to already present lists. I think, most benefits of that class can be achieved by using list conversion and RULE pragma. what i propose should allow to convert algorithm dealing with strings into algorithm dealing with ByteStrings, simply by changing import statement View patterns?.. Also, I think that some general optimization that can fold computations together (like supercompilation) will certainly help here. it's a cute goal - keep Haskell strings easy of use but add ByteString performance Completely agree, this is a noble goal. But ByteStrings aren't polymorphic. So they cannot satisfy your class. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
David said: I'd be interested with breaking the dependency on OpenSSL, for various reasons: [snip] Can't say I'm surprised by these. Its unfortunate the situation hasn't improved. I recall a half decent O'Reilly book on OpenSSL but if you weren't using it as a cookbook (and wanted a 1-off solution) then it wasn't so useful. So, a replacement would need to be a complete replacement for TLS. I did in fact try to start with this, implementing my own simpler TLS-ish protocol, using crypto primitives directly. It took a group of crypto experts about 5 minutes to punch 3 different holes in the protocol You could have gone to Hackage and checked your protocols correctness using CPSA, not that the side-channel attacks would be discovered by such a tool. That said, with the Haskell Crypto API stabilizing, I've been toying with the project of a pure Haskell TLS implementation, which would solve the annoying dependency issue while hanging on to a hardened protocol. I'm releasing crypto-api-0.1 on Tuesday so if you have any last minute comments now is the time! However, this is also far from a simple endeavor, especially if the implementation is to be hardened against side-channel attacks, which I'm not even sure is possible in Haskell. Well, to determine if that's possible we'd need a definition of side-channel attack which is counter to many definitions of side-channel ;-). Perhaps a list of common ones OpenSSL thinks it addresses would give us a good start. If you start on such a task (Haskell TLS) then perhaps you could drop a line to l...@h.o or c...@h.o? Cheers, Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
On 6 September 2010 20:18, John Lato jwl...@gmail.com wrote: Can you give an example of a Functor that doesn't have pure? I think it's Pointed Functors which are useful; not Functor by itself. Strictly speaking is Pair one? The current implementation tacks on monoid. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graphics.Drawing
On Mon, Sep 6, 2010 at 5:29 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 6 September 2010 21:57, han e...@xtendo.org wrote: So the question is: Do you agree that Graphics.Rendering.OpenGL actually should have been Graphics.OpenGL (or just OpenGL) for wieldiness? I think Graphics.OpenGL would have sufficed, unless there was sufficient reason to want to group it with other rendering-specific modules. I'm relatively new to the Haskell community, and one thing that's bugged me a bit is that there doesn't seem to be a convention (aside from common sense) for segmenting the module namespace as there is with Java (my other primary language). If you're not familiar with Java's conventions: Each package producer is encouraged to prefix all their released packages with a reversed dns name (more or less, I don't recall the exact term). For example, if Galois were to release a Java OpenGL package, it would be named something like com.galois.graphics.opengl. This makes it fairly easy to differentiate between different implementations of similar things -- or just to reduce namespace collisions. This comes at the expense of typing a bit more, but no one particularly cares in the java community because the IDEs take care of that. Anyway, I'm curious how module namespace collisions/pollution will be handled in Haskell over the next 5-10 years. Package hiding works in some cases, but it seems like that will fail if you ever need to use capabilities from packages that conflict within the same project. Is this actually a problem, or am I worried about nothing? --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
On Mon, Sep 6, 2010 at 12:45 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: David said: I'd be interested with breaking the dependency on OpenSSL, for various reasons: [snip] Can't say I'm surprised by these. Its unfortunate the situation hasn't improved. I recall a half decent O'Reilly book on OpenSSL but if you weren't using it as a cookbook (and wanted a 1-off solution) then it wasn't so useful. Exactly. I managed to piece together the behavior I wanted by careful inclusion and omission from the O'Reilly book, but even it is more a book of lore and tricks than a real reference manual. Given the shape of the API, unfortunately I suspect that it's quite hard to get any better. So, a replacement would need to be a complete replacement for TLS. I did in fact try to start with this, implementing my own simpler TLS-ish protocol, using crypto primitives directly. It took a group of crypto experts about 5 minutes to punch 3 different holes in the protocol You could have gone to Hackage and checked your protocols correctness using CPSA, not that the side-channel attacks would be discovered by such a tool. Interesting. I had seen CPSA announced at one point, but there appears to be no documentation whatsoever. Did I miss the doc links? That said, with the Haskell Crypto API stabilizing, I've been toying with the project of a pure Haskell TLS implementation, which would solve the annoying dependency issue while hanging on to a hardened protocol. I'm releasing crypto-api-0.1 on Tuesday so if you have any last minute comments now is the time! I'll take a look, but I've been loosely following and don't recall any major objections. However, this is also far from a simple endeavor, especially if the implementation is to be hardened against side-channel attacks, which I'm not even sure is possible in Haskell. Well, to determine if that's possible we'd need a definition of side-channel attack which is counter to many definitions of side-channel ;-). Perhaps a list of common ones OpenSSL thinks it addresses would give us a good start. The two large families of side-channel attacks that I know of and that have been popular (== successful) recently are: - Simple timing attacks: If code path A takes longer than code path B to execute, an attacker can use that information to reverse engineer the outcome of branching tests, and from there possibly recover secret key material. This is particularly nasty because the attack can be carried out remotely, by repeatedly executing the protocol in a way that exercises the vulnerable code path. - Cache state attacks: If code path A has different data access patterns than code path B, it may be possible to deduce which was executed by examining CPU cache statistics. This attack is more theoretical than practically useful, because it requires local access to the CPU executing the crypto code, and that there be little else executing on the system to pollute the cache stats. But I do recall a couple of publications that showed OpenSSL being successfully attacked to some extent through CPU cache analysis. IMHO the former is the big one that needs to be protected against, I won't really lose any sleep over the second one just yet. The definition of a simple timing attack can be basically boiled down to: any branching in the code must be to two alternatives with equal cost (or thereabouts, sufficiently close to be indistinguishable from timing noise). For instance, if comparing two hashes for equality, the code should not exit early if a difference is found, as that would leak to the attacker the number of bytes of his hash that were correct. This is incidentally one component in the successful attack against the Xbox 360's security system: they were comparing hashes with memcmp(), which exits early on a difference, enabling an attacker to determine the correct hash for a modded firmware by brute force. This is fundamentally at odds with lazy evaluation, the ultimate early exit. All crypto code needs to be completely strict to resist timing attacks, or at least very carefully lazy. In a garbage collected language, the code also needs to take care to avoid allocating significantly more in one branch than in the other, lest the pauses induced by garbage collection give away hints as to the chosen code path (though arguably, the GC behavior in a complex program is sufficiently unguessable for an attacker to not be an issue). Am I making sense? Another of my tentative projects was to write a C library that implements popular crypto building blocks, with a large battery of tests for correctness and resistance to timing attacks. Getting resistance to timing attacks is somewhat simpler (though still treacherous) in C, and having such a library available for protocol builders would be quite valuable. Sadly, time is a heartless bitch and continually gives less of itself than I would need to do all these things.
Re: [Haskell-cafe] Graphics.Drawing
creswick: On Mon, Sep 6, 2010 at 5:29 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 6 September 2010 21:57, han e...@xtendo.org wrote: So the question is: Do you agree that Graphics.Rendering.OpenGL actually should have been Graphics.OpenGL (or just OpenGL) for wieldiness? I think Graphics.OpenGL would have sufficed, unless there was sufficient reason to want to group it with other rendering-specific modules. I'm relatively new to the Haskell community, and one thing that's bugged me a bit is that there doesn't seem to be a convention (aside from common sense) for segmenting the module namespace as there is with Java (my other primary language). Anyway, I'm curious how module namespace collisions/pollution will be handled in Haskell over the next 5-10 years. Package hiding works in some cases, but it seems like that will fail if you ever need to use capabilities from packages that conflict within the same project. Well, we have a single global namespace for some 30k modules on Hackage. People are encouraged to partition their packages via top level names, such as Control.* or System.* An tree structure that is roughly followed, http://haskell.org/haskellwiki/Hierarchical_module_names However, when this was planned, I don't think we expected to go from 100 modules to 30k modules in 4 years, and there's been little work on thinking about how to structure the module system at this scale, other than work on explicit package naming and versioning. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
You could have gone to Hackage and checked your protocols correctness using CPSA, not that the side-channel attacks would be discovered by such a tool. Interesting. I had seen CPSA announced at one point, but there appears to be no documentation whatsoever. Did I miss the doc links? There's lots of documentation: $ cabal unpack cpsa $ cd cpsa* $ cd doc $ ls *.pdf -- or you might have to build from .tex, I can't recall. The two large families of side-channel attacks that I know of and that have been popular (== successful) recently are: ... timing and cache miss attacks ... Am I making sense? So much sense it's painful. (that's a 'yes') Another of my tentative projects was to write a C library that implements popular crypto building blocks, with a large battery of tests for correctness and resistance to timing attacks. But how does that prevent a timing-based information flow if the consuming Haskell application is the one performing the branch? Are you assuming all information flow in the Haskell program is so high-level its not cryptographically important, thus protecting these low-level primitives is sufficient? Also, if you feel any of these tests would fit into the Test.Crypto module (or a submodule) then please feel free to send in a patch or start some discussion. Cheers, Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: hledger 0.12.1
I'm pleased to announce hledger 0.12.1, with a new web interface and bugfixes. Thanks to Ben Boeckel and David Patrick for their help this time around. Installation docs, linux/mac/windows binaries and more are at http://hledger.org and http://hackage.haskell.org/package/ hledger . Release notes: 2010/9/6 hledger 0.12.1 * web: new, better web ui; accounts are now a permanent sidebar; add form uses auto-completing combo fields * installing: fix a build error with parsec 3 (#22) * installing: require exactly matching hledger-lib version for more robust builds * installing: explicit data-object dependency to ensure hledger and hledger-lib use the same time version * installing: explicit hamlet dependency for more robust building * installing: build threaded and with warnings * installing: drop -fweb610 flag * installing: add gtk2hs-buildtools dependency needed to build with -fchart * installing: require cabal 1.6 or greater * add -D/--daily flag * register: with --depth, clip account names or aggregate postings rather than excluding them * fix !include with deeply nested directories (#21) * fix obscured date parse errors with parsec 3 * handle unicode better in errors * fix a ghc 6.12.3 error when running interpreted Stats: 50 days and 90 commits since last release, now at 5741 lines of code with 136 tests and 41% unit test coverage. Goals for the next release are: 1. implement a plugin mechanism, probably by searching for hledger-* named binaries in $PATH at startup and handing over control. This should make packaging easier and more scalable. 2. move web/vty/chart features into their own packages. 3. developer docs 4. a public project ledger tracking expenses/income/resources Problem reports and all help are welcome; additional bugfix releases will appear on hackage if needed. Best, -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] running ghci simply
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/6/10 04:08 , Ivan Lazar Miljenovic wrote: On 6 September 2010 18:00, Johann Bach johann.bach1...@gmail.com wrote: Regarding runhaskell: the last time I tried it, it compiled the program, but I want to use the interpreter. I have a script-like application in which the code will be changing frequently and I want to run it and see the results quickly. Unless on Windows it does something differently, that shouldn't happen: on *nix it just interprets the file and doesn't compile it. Even interpreted Haskell is actually compiled to bytecode first. This shouldn't be visible when invoked via runhaskell/runghc/ghc -e, though. - -- 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/ iEYEARECAAYFAkyFXiAACgkQIn7hlCsL25V5gQCdFP2f5PovNlx25aa/ER1wVrtc +psAn1DpE5VFor2m3mmG6xc5atNlBaSf =doJA -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Projects that could use student contributions?
Hello, The Happstack web application framework would be glad to sponsor any students interested in contributing. We almost always have a collection of small, interesting tasks to tackle which do not require a deep understanding of Happstack or Haskell. When you are closer to actually giving the assignment, let me know and I can produce a list of possibilities. - jeremy On Aug 31, 2010, at 3:52 PM, Brent Yorgey wrote: Hi all, This fall I'll be teaching a half-credit introduction to Haskell to some undergrads. As a final project I am thinking of giving them the option of (instead of developing some program/project of their own) contributing to an existing open-source Haskell project. Of course, this requires the existence of projects they could contribute to. I'm sure they exist, but need your help to figure out what they are. So, do you maintain, or know of, any projects with the following characteristics? * might conceivably be interesting to undergraduate CS majors * simple enough that someone could make some non-trivial contributions in the space of 3 or 4 weeks * could use some help! This is a little non-traditional, so we'll see how it goes! -Brent ___ 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: secure-sockets version 1.0
On Mon, Sep 6, 2010 at 2:08 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: You could have gone to Hackage and checked your protocols correctness using CPSA, not that the side-channel attacks would be discovered by such a tool. Interesting. I had seen CPSA announced at one point, but there appears to be no documentation whatsoever. Did I miss the doc links? There's lots of documentation: $ cabal unpack cpsa $ cd cpsa* $ cd doc $ ls *.pdf -- or you might have to build from .tex, I can't recall. Right, I discovered that shortly after sending my email and making a fool of myself. The two large families of side-channel attacks that I know of and that have been popular (== successful) recently are: ... timing and cache miss attacks ... Am I making sense? So much sense it's painful. (that's a 'yes') Another of my tentative projects was to write a C library that implements popular crypto building blocks, with a large battery of tests for correctness and resistance to timing attacks. But how does that prevent a timing-based information flow if the consuming Haskell application is the one performing the branch? Are you assuming all information flow in the Haskell program is so high-level its not cryptographically important, thus protecting these low-level primitives is sufficient? Good question. No, not necessarily. In theory all the code of a program that performs crypto, including the user code that generates the data being encrypted (in the case of a transport protocol) needs to be hardened against side-channel analysis. In practice, aside from greatly increasing the cost of developing the software, there is somewhat less to be gained: when considering attacks against higher level protocols, it usually comes down to finding a design flaw (e.g. TLS renegociations are not cryptographically bound to the enclosing channel, allowing an attacker to inject arbitrary prefixes to victim transmissions) or a direct implementation error (e.g. OpenSSL omits to check the well-formedness of the server certificate in certain situations, leading to arbitrary code execution). Timing attacks additionally require that you are aiming squarely at a fairly small piece of code, to avoid confounding your measurements with other changes in codepath. In theory it is possible to perform a timing attack on large pieces of code, but in practical attacks it comes down to varying the execution path of a small subset of the whole stack, while keeping the rest as constant as possible. And the small building blocks of protocols are, roughly speaking, basic crypto ops and comparisons. So, if you can ensure that those have good timing properties, you're in rather good shape. An attacker might still be able to time the higher level protocol, but the outcome would be useless, e.g., If I present an invalid cert, the server responds with latency A, whereas a valid cert results in latency B vs. latency is a function of the key bits, a function that I can use to compute a valid key!. Of course, I'm handwaving slightly. Of course, in a perfect world, the higher level protocol should be treated with the same attention to timing attacks as the basic blocks. However, it seems to me that in the real world, basic crypto blocks are more susceptible to timing attacks, whereas high level protocols are more susceptible to design flaws or simple implementation errors. Haskell is a strong ally to eliminate the latter kinds of flaws, while C is a better ally to produce code that executes with specific timing properties. At least, this is my perception of the situation, and the reasoning behind having a C library for basic blocks, but implementing high level protocols in Haskell. Perhaps more experienced Haskell hackers will disagree (much to my delight, if it means I can write more Haskell and less C!). Also, if you feel any of these tests would fit into the Test.Crypto module (or a submodule) then please feel free to send in a patch or start some discussion. Once I reach the point of implementing crypto code, I'll certainly add to the common test suite rather than roll my own. - Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Paralelism and Distribution in Haskell
Hi fellow haskellers, I'm interested in the performance of parallel and/or distributed implementations in haskell language. For example, supose I want to develop an application that distributes a computation between many multicore computers, what are the advantages I can take from haskell in that? Anyone who has experience doing distributed computing with haskell, and could point some diferences between haskell and other languages? Any feedback is very much apreciated. Thanks. Regards. -- == Ivan Sichmann Freitas Engenharia de Computação 2009 UNICAMP http://identi.ca/ivansichmann Grupo Pró Software Livre UNICAMP - GPSL == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Paralelism and Distribution in Haskell
ivansichfreitas: Hi fellow haskellers, I'm interested in the performance of parallel and/or distributed implementations in haskell language. For example, supose I want to develop an application that distributes a computation between many multicore computers, what are the advantages I can take from haskell in that? Anyone who has experience doing distributed computing with haskell, and could point some diferences between haskell and other languages? Any feedback is very much apreciated. Thanks. The primary work in this area has been GUM/GPH and GDH, these days being led from St Andrews, http://www-fp.cs.st-andrews.ac.uk/wordpress/ * GUM, a parallel execution layer to allow GHC 'par' strategies and friends to run transparently across nodes, on top of an underlying message passing layer. http://www.macs.hw.ac.uk/~dsg/gph/ GHC implements the same abstractions for shared memory multicores. * Glasgow Distributed Haskell, an extension of the Parallel Haskell language to support distribution and fault tolerance, http://www.macs.hw.ac.uk/~dsg/gdh/ These systems run on a fork of GHC's runtime. Recent work is underway to merge some of the facilities back into mainline GHC. http://hackage.haskell.org/trac/ghc/wiki/HackPar There is also the Eden project, which I think is another implementation of a parallel Haskell model, with features to support distribution. The key players to talk to are Kevin Hammond, Jost Berthold, Hans-Wolfgang Loidl, Philip Trinder et al. Besides traditional language research projects, there are also various open source libraries on Hackage to support distributed computation in Haskell to some degree or another. For example: A framework for distributed STM, http://hackage.haskell.org/package/DSTM Holumbus-Distribution, distributed data structures like Chan, MVar or functions http://hackage.haskell.org/package/Holumbus-Distribution Holumbus map-reduce skeleton http://hackage.haskell.org/package/Holumbus-MapReduce net-concurrent is a simple haskell library for doing parallel computation on several computers using the network http://hackage.haskell.org/package/net-concurrent -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Projects that could use student contributions?
Hi Brent, ditto what Jeremy said. hledger is an end-user app with lots of needs including code design review, performance and laziness analysis, quickcheck/smallcheck testing, development process refinement, web design, and features/fixes of all sizes. I'd be happy to mentor volunteers. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Paralelism and Distribution in Haskell
http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell Although the last two edits on that page are from 2010 and 2009. So what *is* the current status of DPH? J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Paralelism and Distribution in Haskell
waldmann: http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell Although the last two edits on that page are from 2010 and 2009. So what *is* the current status of DPH? Note that DPH is a programming model, but the implementation currently targets shared memory multicores (and to some extent GPUs), not distributed systems. Since GHC 6.10 DPH was in technology preview mode (alpha), since 6.12 it is more stable, and more reliable, though significant work is still happening with the vectorizer in GHC HEAD (so expect even more reliable performance in GHC 6.14) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Paralelism and Distribution in Haskell
Don Stewart dons at galois.com writes: Note that DPH is a programming model, but the implementation currently targets shared memory multicores (and to some extent GPUs), not distributed systems. Yes. I understand that's only part of what the original poster wanted, but I'd sure want to use ghc-generated code on a (non-distributed) GPU. I keep telling students and colleagues that functional/declarative code automatically parallelizes, with basically no extra effort from the programmer (because it's all in the compiler) - but I would feel better with some real code and benchmarks to back that up. GPU computing via ghc could be a huge marketing opportunity - if it works, it should be all over the front page of haskell.org? J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Paralelism and Distribution in Haskell
waldmann: Don Stewart dons at galois.com writes: Note that DPH is a programming model, but the implementation currently targets shared memory multicores (and to some extent GPUs), not distributed systems. Yes. I understand that's only part of what the original poster wanted, but I'd sure want to use ghc-generated code on a (non-distributed) GPU. I keep telling students and colleagues that functional/declarative code automatically parallelizes, with basically no extra effort from the programmer (because it's all in the compiler) - but I would feel better with some real code and benchmarks to back that up. Well, that's not really a good thing to say. Some subsets of Haskell automatically parallelize (like the array combinator libraries), others require simple annotations (like parallel strategies). Others are more explicit, like concurrent collections. There are many programming models, with varying degrees of power/usability. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Paralelism and Distribution in Haskell
functional/declarative code automatically parallelizes, Well, that's not really a good thing to say. Sure, sure, and I expand on the details in my lectures. But in advertising (the elevator sales pitch), we simplify. Cf. well-typed programs don't go wrong. - Johannes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Paralelism and Distribution in Haskell
waldmann: functional/declarative code automatically parallelizes, Well, that's not really a good thing to say. Sure, sure, and I expand on the details in my lectures. But in advertising (the elevator sales pitch), we simplify. Cf. well-typed programs don't go wrong. Good! I think we could all agree on a slogan based on the point that Haskell approaches take parallelism from difficult tasks to easy tasks. -- Don expectations management Stewart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] overloaded list literals?
Am Montag, den 06.09.2010, 19:38 +0400 schrieb Bulat Ziganshin: btw, i also had proposal to automatically convert typeclasses used in type declarations into constraints, so that: putStr :: StringLike - IO () treated as putStr :: StringLike s = s - IO () This blurs the distinction between classes and types, which are two fundamentally different concepts in Haskell. In addition, it works only for special cases. I would like the language to be simple. Alas, more and more sugar is added to Haskell, which makes it unnecessarily complicated. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Grempa 0.1.0, Embedded grammar DSL and LALR parser generator
On Mon, Sep 6, 2010 at 2:45 PM, Olle Fredriksson
fredriksson.o...@gmail.com wrote:
expr :: Grammar Char E
expr = do
rec
e - rule [ Plus @ e # '+' # t
, id @ t
]
t - rule [ Times @ t # '*' # f
, id @ f
]
f - rule [ id @ '(' # e # ')'
, Var @ 'x'
]
return e
Looks like Applicative style. This is good, even while I don't really
know why we are seeing @ and # instead of $ and *.
How does Grempa compare with other parsing libraries/tools, such as
Parsec, Attoparsec and Happy, with regard to ease of use and
performance?
Cheers! =)
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Paralelism and Distribution in Haskell
Before Haskell took off with parallelism, it was assumed that Haskell would be trivial to run concurrently on cores because majority of Haskell programs were pure, so you could simply run different functions on different cores and string the results together when your done It turned out that using such a naive method created massive overhead (to the point where it wasn't worth it), and so different concurrent paradigms were introduced into Haskell to provide parallelism (nested data structures, parallel strategies, collections, STM). In I believe almost every case for these algorithms, there is a compromise between ease of implementation vs performance gains. Haskell is still by far one of the best languages to deal with concurrency/parallelism. In most other conventional languages used today (with are imperative or multi-paradigm), parallelism breaks modularity/abstraction (which is one of the main reasons why most desktop applications/games are still single core, and the few exceptions use parallelism in very trivial cases). This is of course mainly to to deal with state (semaphores/mutex). Although it is possible to program in other languages using 'pure' code, its often very ugly (and in that case you may as well use Haskell) On Tue, Sep 7, 2010 at 8:37 AM, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: Don Stewart dons at galois.com writes: Note that DPH is a programming model, but the implementation currently targets shared memory multicores (and to some extent GPUs), not distributed systems. Yes. I understand that's only part of what the original poster wanted, but I'd sure want to use ghc-generated code on a (non-distributed) GPU. I keep telling students and colleagues that functional/declarative code automatically parallelizes, with basically no extra effort from the programmer (because it's all in the compiler) - but I would feel better with some real code and benchmarks to back that up. GPU computing via ghc could be a huge marketing opportunity - if it works, it should be all over the front page of haskell.org? J.W. ___ 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] Re: Paralelism and Distribution in Haskell
*Mistake, in where I said majority of Haskell programs were pure I meant majority of code in Haskell programs was pure On Tue, Sep 7, 2010 at 11:07 AM, Mathew de Detrich dete...@gmail.comwrote: Before Haskell took off with parallelism, it was assumed that Haskell would be trivial to run concurrently on cores because majority of Haskell programs were pure, so you could simply run different functions on different cores and string the results together when your done It turned out that using such a naive method created massive overhead (to the point where it wasn't worth it), and so different concurrent paradigms were introduced into Haskell to provide parallelism (nested data structures, parallel strategies, collections, STM). In I believe almost every case for these algorithms, there is a compromise between ease of implementation vs performance gains. Haskell is still by far one of the best languages to deal with concurrency/parallelism. In most other conventional languages used today (with are imperative or multi-paradigm), parallelism breaks modularity/abstraction (which is one of the main reasons why most desktop applications/games are still single core, and the few exceptions use parallelism in very trivial cases). This is of course mainly to to deal with state (semaphores/mutex). Although it is possible to program in other languages using 'pure' code, its often very ugly (and in that case you may as well use Haskell) On Tue, Sep 7, 2010 at 8:37 AM, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: Don Stewart dons at galois.com writes: Note that DPH is a programming model, but the implementation currently targets shared memory multicores (and to some extent GPUs), not distributed systems. Yes. I understand that's only part of what the original poster wanted, but I'd sure want to use ghc-generated code on a (non-distributed) GPU. I keep telling students and colleagues that functional/declarative code automatically parallelizes, with basically no extra effort from the programmer (because it's all in the compiler) - but I would feel better with some real code and benchmarks to back that up. GPU computing via ghc could be a huge marketing opportunity - if it works, it should be all over the front page of haskell.org? J.W. ___ 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 9/6/10 2:35 AM, Ivan Lazar Miljenovic wrote: Well, if we consider what this does, pure is equivalent to singleton for container types. The actual definition of pure (or any other aspect of Pointed) doesn't require Functor; however there are properties for types that are instances of Functor and Pointed. Right, that's what I was meaning to highlight. If we were doing this in Coq, for example, then not having Functor as a superclass of Pointed would mean that we'd need a third class PointedFunctor which has both as superclasses. In Haskell, since we don't have proofs, PointedFunctor wouldn't have any methods and would therefore just be unnecessary complication. Though this raises the question of which one makes more sense to keep around: Pointed (with no superclass), or PointedFunctor. So, from a proof/testing POV having Functor as a superclass is nice; from an implementation POV it doesn't seem to be needed. Though, again, I wonder what the use case would be. Your example of singleton collections doesn't seem quite right. I'd expect the singleton functions to obey various spatial laws (i.e., module-like or vector space-like laws). For example, union (singleton a) x = insert a x This isn't exactly like Applicative because 'a' is an element instead of a function. And it's not quite like Alternative either, since it only requires union to be a semigroup instead of a monoid. However, I can see some pointed functors that don't have this law, either because insert or union don't make sense or because the obvious implementations don't fit the pattern. Consider, for instance, the ZipList applicative functor which has pure=repeat. It satisfies the pointed law just fine, but it's not clear what insert or union should mean (interleaving, perhaps? It still wouldn't be an Alternative though). Perhaps this just means that union/insert should be part of some other class. Of course, I'd expect singleton to obey the pointed law as well, so that other class would (most likely) be a subclass of pointed functors. In any case, it does mean there's something of a mismatch between singleton vs return/pure/point/unit. -- 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 9/6/10 1:33 PM, David Menendez wrote: For that matter, can you even describe what pure is intended to do without reference to* or join? As already stated: fmap f . pure = pure . f -- 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 Mon, Sep 6, 2010 at 10:22 PM, wren ng thornton w...@freegeek.org wrote: On 9/6/10 1:33 PM, David Menendez wrote: For that matter, can you even describe what pure is intended to do without reference to* or join? As already stated: fmap f . pure = pure . f That's pretty general. For lists, the functions having that property include const [], \x - [x,x], and repeat. In fact, I think *every* appropriately-typed function satisfies that law. Does anyone know of a counter-example? -- 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] Pointed (was: Re: Restricted type classes)
On 9/6/10 11:50 AM, Gábor Lehel wrote: On Mon, Sep 6, 2010 at 5:11 PM, John Latojwl...@gmail.com wrote: But please don't make Pointed depend on Functor - we've already seen that it won't work for Bloom filters. I think most people have been using Pointed merely as shorthand for Pointed Functor -- in the same way that Applicative isn't called ApplicativeFunctor, even though that's what it is. So if it doesn't work for Bloom filters, the reason is that Bloom filters aren't pointed functors. Exactly. For my part I don't particularly care whether the class defining unit requires fmap or not. Though, as I've mentioned earlier, I don't see any particular reason for omitting the dependency. In particular, one of the primary complaints against the Monad class is precisely the fact that it *fails* to mention the Functor class as a (transitive) dependency. Why should we believe that making unit independent from fmap will fare any better? The unit natural transformation of pointed functors is not the same as any old inclusion function--- even if they are forced to agree when both are defined. Bloomfilters are not pointed functors. This is required, because bloomfilters are not structure preserving! But bloomfilters aren't terribly special in allowing a scalar type to be lifted into them. Vector spaces do the same thing; so do modules; so does path completion; so do free monoids; so does inclusion of real numbers into complex;... But one thing all of these examples has in common is that there is some particular structure which is preserved by the lifting process. The associativity between scalar multiplication and vector scaling, being one example. It's not clear to me that the singleton function for bloomfilters has any analogous structure it's preserving. Bloomfilters can be thought of as a sort of completion of the set of elements inserted into them, but there isn't much we can do to work with that. One thing I am opposed to, however, is introducing a new class without being explicit about the laws and properties required of instances. If the class does not have a set of laws that it obeys, then it will only lead to confusion and poor design. Why bother giving a name to something that doesn't have a special and interesting structure? This failure of specification has led to problems in the MonadPlus class as well as the Alternative class, where people weren't sure what sort of structure those classes were supposed to be representing, and therefore came to conflicting conclusions. In what sense can we define a unique parametric inclusion function that fails to meet the requirements of a pointed functor? What properties will this parametric inclusion function have, what laws will it require? Pointed functors do have laws; and explicitly mentioning these laws allows simplifying the definition of other classes (e.g., Applicative). But what laws do pointed non-functors have which make them a proper subclass of pointed functors? If we cannot come up with anything other than the parametricity of inclusion, then that would make me opposed to introducing this separate class. The only laws I can come up with for pointed types all make reference to some additional structure like the pointed type being a semiring, a functor, etc. I'm not sure that these additional structures all mean the same thing with the inclusion function they require, so I am uneasy with conflating them into a single class which satisfies no laws on its own. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] container-classes (was: Restricted type classes)
On 7 September 2010 02:53, John Lato jwl...@gmail.com wrote: I'd like to make one more argument in favor of my preference for more splitting of type classes. IMO it's beneficial to split up classes to minimize unnecessary dependencies. That is, while e.g. Monoid is very useful for containers, many container methods won't need it, e.g. elem or filter. When you divide the type classes so only what's necessary is required, more data structures will be able to meet those criteria, which in turn makes the class more generally useful. Well, my current work is to implement restricted versions of the various type classes (I'm undecided if they should be split off into a separate package or not) and then have the Data.Containers module basically define type aliases (which will probably still use Monoid though, since the vast majority of containers are able to be empty). As an example, I have an extension to iteratee which uses raw buffers for holding data. This allows it to operate in truly constant memory (only one allocation, deallocated when it's finished), which has resulted in performance benefits. Unfortunately there is not a good Monoid instance for this type because appending buffers is not possible. By introducing the NullPoint class (equivalent to mempty of Monoid) in iteratee, my raw buffer extension is able to re-use several iteratee functions which it would not be able to if I had require Monoid instead of NullPoint. Hmmm, splitting up Monoid might make sense. I'll have a think about that (I was going to just keep Monoid as is since no constraints are needed. -- 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] container-classes (was: Restricted type classes)
On 9/6/10 12:53 PM, John Lato wrote: I'd like to make one more argument in favor of my preference for more splitting of type classes. FWIW, I agree that more splitting is generally good. This is one of the problems I have with the various proposals for a ListLike class. They conflate the cons-list like, sequence like, string like, set like (i.e., Boolean algebra), and collection like (e.g., filterable) functions with nary a care. This in turn means that fewer types can implement the class, and moreover that we can state fewer properties about the instances which are there (e.g., what their running time complexity is or should be). The countervailing force, for me, is the question of whether the smaller classes can still be well-defined--- as discussed separately in the Pointed thread fork. If MPTCs are involved, the other consideration is to make sure that type inference for common usage isn't borked by splitting things. Even though it's a common argument from others, I don't care about defining one instance with five methods vs five instances with one method each. This last argument seems to be one of the leading problems with redefining the numeric hierarchy. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] container-classes
On 9/6/10 11:46 PM, Ivan Lazar Miljenovic wrote: Well, my current work is to implement restricted versions of the various type classes (I'm undecided if they should be split off into a separate package or not) and then have the Data.Containers module basically define type aliases (which will probably still use Monoid though, since the vast majority of containers are able to be empty). [...] Hmmm, splitting up Monoid might make sense. I'll have a think about that (I was going to just keep Monoid as is since no constraints are needed. Bear in mind that splitting up Monoid also means you can define a(n additive) Semigroup class for non-nullable types. I think that's a step in the right direction since it lets you include common 'exotic' collections like non-empty lists. -- 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
2010/9/7 Gábor Lehel illiss...@gmail.com: *That said*, I actually have nothing at all against splitting the 'a - f a' method out into a separate class if you think it's useful, whether you call it Pointed or something else. (And `class (Pointed f, Functor f) = PointedFunctor f` is sort of cute.) It might be cute, but until we get class aliases [1] this results in yet another class to make your data type an instance of, and what's more it's one that doesnt' even give you anything. I think it makes much more sense to have Functor, Pointed and (Functor f, Pointed f) = Applicative f rather than a useless intermediary class. If, however, we could get class aliases _for free_ (i.e. something like class alias PointedFunctor f = (Functor f, Pointed f) for which all instances of Functor and Pointed are automatically instanced of PointedFunctor), then I can see that as being something nice to have. [1]: http://www.haskell.org/haskellwiki/Context_alias -- 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] Restricted type classes
On 7 September 2010 12:18, wren ng thornton w...@freegeek.org wrote: On 9/6/10 2:35 AM, Ivan Lazar Miljenovic wrote: Well, if we consider what this does, pure is equivalent to singleton for container types. The actual definition of pure (or any other aspect of Pointed) doesn't require Functor; however there are properties for types that are instances of Functor and Pointed. Right, that's what I was meaning to highlight. If we were doing this in Coq, for example, then not having Functor as a superclass of Pointed would mean that we'd need a third class PointedFunctor which has both as superclasses. In Haskell, since we don't have proofs, PointedFunctor wouldn't have any methods and would therefore just be unnecessary complication. Though this raises the question of which one makes more sense to keep around: Pointed (with no superclass), or PointedFunctor. So, from a proof/testing POV having Functor as a superclass is nice; from an implementation POV it doesn't seem to be needed. Though, again, I wonder what the use case would be. Your example of singleton collections doesn't seem quite right. I'd expect the singleton functions to obey various spatial laws (i.e., module-like or vector space-like laws). For example, union (singleton a) x = insert a x This isn't exactly like Applicative because 'a' is an element instead of a function. And it's not quite like Alternative either, since it only requires union to be a semigroup instead of a monoid. Well, I think the ability to create singleton values is a nice function to abstract away into a type class. Whether we can prove something or not is, however, a different story. Perhaps this just means that union/insert should be part of some other class. That is part of the plan (I'm tentatively calling the class with the insert method Buildable or Extendable); this means that if a type is an instance of Monoid (for mempty), Buildable/whatever (for insert) and Foldable (for foldr), then we can possibly define a build-fusion rule (note: I dont' think this will work on Sets, etc. unless we have some way of guarantee-ing that the folding function is strictly monotonic). Note also that we can then define that singleton = flip insert mempty (but in general this might not be ideal; Sets, for example, don't have the Ord constraint for singleton). Of course, I'd expect singleton to obey the pointed law as well, so that other class would (most likely) be a subclass of pointed functors. In any case, it does mean there's something of a mismatch between singleton vs return/pure/point/unit. Not quite sure what you mean by a mis-match -- 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
