December 2009 - Haskell-Cafe

lhs2tex + pretty print
by rodrigo.bonifacio 10 Dec '09

10 Dec '09

2 1

Finding substantial examples of Cabal Setup files
by Jon Strait 10 Dec '09

10 Dec '09

Hi all, I was looking through some of the Hackage packages to find examples of how developers are extending UserHooks in their Setup files, but it wasn't easy, since the great majority of Cabal Setup files in Hackage simply require only the standard line of 'main = defaultMain' or 'defaultMainWithHooks' with a standard UserHooks value. So, I started hacking together a little Emacs Lisp script to walk through all the packages in the Hackage archive and report on the Setup files that looked interesting enough to serve as non-trivial examples. Here is the latest result: http://www.moonloop.net/haskell/docs/cbs-custom.html Jon

1 0

ANNOUNCE: unicode-symbols-0.1.1
by Roel van Dijk 10 Dec '09

10 Dec '09

Hello, I would like the announce the release of my package unicode-symbols: http://hackage.haskell.org/package/unicode-symbols It offers alternative symbols for a number of common functions and operators from the base and containers packages. When used in combination with the language extension UnicodeSyntax you can write really nice code. The only thing missing is a nice λ symbol. The documentation on hackage should be pretty self explanatory. For each symbol the documentation gives its exact definition. The source code however, probably due to a bug in hscolour, is totally unreadable. To view the sources simply download the package and use a text editor. I tried to be conservative with the choice of unicode symbols. I have defined the division sign (÷) to be (/). But it could just as well be defined as 'div'. I do not know what would be the logical choice. Another choice that could lead to some discussion is the definition of (⊂) to be 'Data.Set.isProperSubsetOf' and (⊆) to be 'Data.Set.isSubsetOf'. An alternative choice would be to have (⊊) for 'isProperSubsetOf' and (⊂) for 'isSubsetOf'. I choose the former because it is more symmetrical with (<) and (≤). This package was inspired by unicode-prelude from Péter Diviánszky: http://hackage.haskell.org/package/unicode-prelude Regards, Roel van Dijk

3 3

Re: Why?
by Casey Hawthorne 10 Dec '09

10 Dec '09

I have not read all/most of the replies. >What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? Please provide examples as I require instruction. A pure functional lanugage allows lazy evaluation, which adds another tool to your modularity toolbox, since it separates control from computation. In a pure functional language state is very carefully isolated from the rest of your program. This makes all sorts of optimizations trivial that are very hard to do in other languages. Optimizations are done in "code algebra", which is very easy to do in Haskell (for pure functions), for example optimizations are harder to do in the "code algebra" of Java. For a better discussion of "code algbra" please see the following book: "Practical Formal Software Engineering: Wanting the Software You Get" Bruce Mills, 2009 -- Regards, Casey

1 0

Re: [Haskell-cafe] Re: Why?
by David Leimbach 10 Dec '09

10 Dec '09

On Thu, Dec 10, 2009 at 6:31 AM, Alberto G. Corona <agocorona(a)gmail.com>wrote: > My understanding is that a pointer to the lazy expression tree for the > calcualtion of the parameter is put it the corresponding location of the > function expression tree. But at any time you can force the evauation before > the call. or the compiler itself. Optimization is possible depending on the > knowledge. What happens if the parameter is an infinite list and the > function handles a few items of it?. > > All of these consideration pales when a programmer has to call a procdure > in a library made by others with no documentation, and no clue about what > the procedure does inside. The purity and the type system removes many > concerns. > That's not a "safe" way to think of 3rd party libraries. It is a convenient claim for promoting the language, and is probably more often than not the case though it does not quite capture the whole truth. unsafePerformIO can exist in any library you import, and while you may think it's pure, you still have to implicitly trust the library writers (unless you bother to look at the source). Take Debug.Trace.trace for example, it's a pure computation, yet causes side effects. Yes, it's a controlled side effect, but a polluted version of the same function signature could "launch the missles" while looking like the function is synonymous with "id". In short unsafePerformIO, while it's "supposed to be" avoided, may not be avoided as much as the advice given to do so :-). Might be interesting to see how many occurrences of unsafePerformIO exist in hackage. I fully realize that someone will probably claim I'm taking this position to the extreme, but I think we're tempted to pretend that all functions with pure signatures are always safe which is another kind of extreme when you consider the existence of backdoors to the Monads that provide the guarantees we're clinging to to talk about how great Haskell is. I think the existence of unsafePerformIO is a bit of an admission that there's some things yet to be figured out to make this system 100% consistent with where we want pure functional programming to be. Dave > > 2009/12/10 David Leimbach <leimy2k(a)gmail.com> > > And that would be true if everything were strict and not partially >> evaluated sometimes :-) >> >> My understanding is the following... (and I could be way off) >> >> Remember that a function of arity N is really N functions of arity 1 with >> their arguments bound one at a time to create a new function along the way. >> At least you *can* write your code that way if you really want to, but the >> laziness might make it such that all the parameters are not bound, due to >> not being "needed" at that moment. Instead a thunk or what some other >> languages might call a "Future" is put in the argument's place, to be >> evaluated when needed. >> >> If Haskell were strict by default, I think your claim of passing >> references around could be true, but my experience with Haskell has been >> that sometimes it's too lazy for me to write the code that I first thought >> would be efficient without a lot f study and refactoring of that code. >> >> I'm sure this gets easier with practice, but it's not something I was >> expecting to be as difficult as it all was. >> >> Dave >> >> On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona <agocorona(a)gmail.com>wrote: >> >>> One more advantage that is not frequently cited >>> >>> Purity permits to pass every parameter of a procedure by reference >>> (giving the pointer) rather that by value giving a copy, and still be sure >>> that the data has not been modified. Besides the safety. this is great >>> language optimization itself. >>> >>> 2009/12/10 Alberto G. Corona <agocorona(a)gmail.com> >>> >>> >>>> >>>> >>>> What material benefit does Haskell derive from being a "pure" >>>> functional language as opposed to an impure one? >>>> >>>> >>>> >>>> Here is my list of benefits of purity (some of them are enhanced by >>>> other features like the type system). >>>> >>>> Purity means referential transparency. that means that the programmer >>>> has no way to modify pure data. That cut the tree of possible programmer >>>> errors.In particular, since there are no variables, every state change must >>>> be in the form o a call to a function with new parameters. each function has >>>> no state change (except when needed and then the type system labels the >>>> stateful code as such)( This enforcement goes in the righ direction for >>>> clarity and readability, maintainability, modularity xxxxxbility. >>>> >>>> Purity also eases paralel processing, since no data is modified, each >>>> process is isolated better. Less opportunities for errors. >>>> >>>> Purity permits lazines because since the execution tree of >>>> an expression has pure, data, can be evaluated later, since it will not be >>>> changed. >>>> >>>> Lazy evaluation eases mathematical reasoning,because mathematics has no >>>> notion of eager evaluation, but to make use of mathematical equations when >>>> the calculation is needed. . >>>> >>>> Mathematical reasoning permits the full use of a long tradition of >>>> mathematical knowledge. This makes code more simple, understandable, >>>> general, proof guarantted and elegant (for those that know the mathematical >>>> domain). This also permits high level optimization of code, both by the >>>> programmer and the compiler. >>>> >>>> for sure there are a few more >>>> >>>> We are superstitious and guided by "nonrational" ideas such is beauty. >>>> but: >>>> >>>> bauauty -> (simplicity -> (less effort to master, less errors) >>>> , utility ->, solve more problems, solve greater >>>> problems >>>> ) >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >

2 3

Re: Why?
by John D. Earle 10 Dec '09

10 Dec '09

My intuition says that laziness and purity are distinct whereas yours says that purity is a necessary condition. This is what needs to be reconciled. I believe that everyone is thinking that lazy evaluation and strict evaluation are similar activities whereas they are profoundly different.

8 9

Re: Why?
by John D. Earle 10 Dec '09

10 Dec '09

I'm going to try to respond to your letters later on when I have more time. This break may also be useful in that it may help the conversation from becoming overheated. I stopped in the middle of a letter and put it in the draft folder so that I could give it greater attention. I was writing it out too quickly. I was responding to Job Vranish. I was responding to his "Though I'm curious as to how a language could be effect free in a practical sense, but not a strict one? could you give an example?" query. My response is already fleshed out. I just have to polish it. Cheers

1 0

Re: Nano-Languages
by John D. Earle 10 Dec '09

10 Dec '09

Earlier in this thread I wrote "... but like so what." In this letter I hope to address what I wrote more fully. The command line option that was found that allows for Haskell source code to be preprocessed accepts a Haskell source code file as an argument. This file defines a preprocessor. It seems to me that such a preprocessor would be undisciplined and capable of wrong doing because the Haskell language does not have all the facilities that a utility such as Happy possesses. Care is needed. It also lacks those facilities that are particular to preprocessors. The paper at http://people.cs.uu.nl/arthurb/data/Macros/Manual.pdf may provide a means to introduce this needed discipline. I do not see how the runtime verses compile time distinction is important, however. You can't really hand craft a preprocessor on the fly that is going to work. I do not believe the paper is explaining itself all that well. What they are referring to as syntax macros given a superficial examination of the paper seem to be the functional language equivalent of a definite clause grammar found in Prolog. So it seems that an effort to bring that goodness that Prolog programmers have enjoyed for years over to Haskell and perhaps to do one or two better. Their emphasis on runtime verses compile time seems like a distraction in that it is merely a necessary condition for inclusion into the Haskell language since Haskell is both compiled and interpreted. It is a problem that would need to be solved. They may have lost sight of what they were doing after having spent so much time working on just this one aspect. Haskell at the present time need external tools. The benefits of bringing in that sort of functionality into the language I would regard as self-evident. It is still a bottom up approach, but a bottom up approach would be easier to implement and it would be desirable for the two worlds to meet, the bottom up and the top down. An important question will be, Will syntax macros work out better than an existing tool such as Happy?

2 5

Re: Why?
by John D. Earle 10 Dec '09

10 Dec '09

To elaborate there is another language that is also a functional language. I won't mention the name so as not to offend anyone. It too is effect free, that is what makes it functional and it is a functional language in the true sense of the term, but it is not effect free in the sense that Haskell is effect free. This other language is effect free in every practical sense whereas Haskell is effect free in a strict sense.

5 4

Re: Why?
by John D. Earle 10 Dec '09

10 Dec '09

What I think might be confusing the situation partially is that there is a difference between the language and its implementation. Any side effect would have been accounted for even though there is a means to side step it and its inclusion may have been perceived as a undesirable and perhaps unnecessary complication. To put it bluntly, it is like how division by zero can be inconvenient.

1 0