December 2009 - Haskell-Cafe

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

10 Dec '09

So my question is, Did the leap from effect free for all practical purposes to effect free in a strict sense yield any material benefits?

1 0

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

10 Dec '09

Laziness is on the logic front end and purity is on the execution back end.

2 1

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

10 Dec '09

Laziness is on the logic front end and purity is on the execution back end.

1 0

Natural Language Processing
by John D. Earle 10 Dec '09

10 Dec '09

Is Parsec capable of parsing a mildly context sensitive language? In particular does it parse a combinatory categorial grammar? Does Haskell have such tools in its shed? What sort of facilities does Haskell have for natural language processing?

5 5

Fwd: [Haskell-cafe] Re: Why?
by Alberto G. Corona 10 Dec '09

10 Dec '09

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 a large list and the function handles a few elements?. All of these consideration pales when a programmer has to call a procedure 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. 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 >> >> >

1 0

Parsec-like parser combinator that handles left recursion?
by oleg＠okmij.org 10 Dec '09

10 Dec '09

There are at least two parser combinator libraries that can deal with *any* left-recursive grammars. That said, Prof. Swierstra's advice to try to get rid of left recursion is still well worth to follow. The first library is described in Frost, Richard, Hafiz, Rahmatullah, and Callaghan, Paul. Parser Combinators for Ambiguous Left-Recursive Grammars. PADL2008. http://cs.uwindsor.ca/~richard/PUBLICATIONS/PADL_08.pdf It handles arbitrary left-recursive grammars, including eps-cycles. It copes with highly ambiguous grammars. It can produce all parses of the input sequence. It parses the input in O(n^4) time with respect to the size of the input. I have tried dealing with left-recursive grammars and too wrote a parser combinator library: http://okmij.org/ftp/Haskell/LeftRecursion.hs It can handle eps-cycles, ambiguity and other pathology. Here is a sample bad grammar: S -> S A C | C A -> B | aCa B -> B C -> b | C A The library is pure and uses no state (monad). Strictly speaking, the library produces a recognizer rather than a parser, or a recognizer that yields a list of fired productions. There are standard ways however to `lift' a recognizer to produce a parse tree. The library is far simpler than than of Frost et al, and does not require explicit labeling of productions. Although the library can be faster than Frost's et al when a parse exists, it currently can be far slower when no parse exists. (It still assuredly terminates.) Both libraries require that the whole input be known in advance: neither library does on-line parsing. The reason has to do with memoization and with the cut-off for the recursion (a productive left-recursive rule shouldn't be applied more times than there are characters in the input). That is quite a disappointment. Therefore, it is well worth to convert the left recursion away, as was described in Doaitse Swierstra's earlier message.

2 1

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

10 Dec '09

While going through the Haskell literature I uncovered a passage that said that, I'm paraphrasing: Complexity was at a premium. The task was very complex and what was needed to get Haskell to achieve its goals was extraordinary. This might explain how laziness kept Haskell pure. Everything was at a premium and this developed a discipline to keep everything streamlined. This suggests that purity had a material benefit, but the problem is it is conceivable that its material benefit was merely psychological. I do not have enough time to study what Stephen wrote at the moment so I will need to revisit it. He cited some references.

1 0

Haskell and sockets
by Johann Höchtl 10 Dec '09

10 Dec '09

Hello, How does Haskell handle sockets? Is it using select or epoll? I ask especially in regard to http://groups.google.com/group/erlang-programming/browse_frm/thread/a73efeb… Regards, Johann

2 2

Re: Allowing hyphens in identifiers
by John D. Earle 10 Dec '09

10 Dec '09

To Underscore or Not to Underscore Richard O'Keefe and I were privately discussing the relative merits of his and my approach. We have come to an agreement. It concerns whether or not hyphens should be replaced with underscores. The following is my response to his most recent letter: I do not believe your approach given what you wrote here will create the sort of ambiguity I feared could be introduced. If an ambiguity results, it could be fixed. As I would put it, you hope to harmonize the word breaking styles by a process similar to though slightly more involved than what is done to remove case sensitivity in some languages. As layout is concerned only leading white space needs to be preserved. Anything else could be regarded as a superstition (not to say that computer scientists are superstitious). What you hope to do is kill two birds with one stone. If the only goal is to run everything through a preprocessor my approach seems to make the greatest sense, but if you also hope to harmonize the representation of word breaking styles, then what you are advocating seems to make greater sense. Your approach seems more consistent with Haskell traditions than mine. Therefore, I concede. You have successfully argued your point.

1 0

Handles with their IOMode in their type
by Bas van Dijk 10 Dec '09

10 Dec '09

Could not get to sleep tonight so I got up and hacked this together: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13782 Does something like this already exist on hackage: If not, I may turn this into a package and upload it tomorrow. Comments, criticism and patches are welcome. regards, Bas

4 4