- Haskell-Cafe - Haskell.org

Fwd: News: FP Complete Offering Free Academic Accounts to FP Haskell Center
by Natalia Muska 25 Jul '13

25 Jul '13

FP Complete Offering Free Academic Accounts to FP Haskell Center San Diego, C.A. (July 25, 2013) FP Complete, the leading developer of commercial Haskell software tools and services, announced today that professors and students will be offered free accounts to FP Haskell Center, the world’s first commercial Haskell IDE and deployment platform. FP Haskell Center is an integrated development and deployment environment written in Haskell, the most popular and purest functional programming language. It consists of two components, the FP Development Environment and the FP Application Server. The FP Development Environment includes a Haskell compiler and a continually updated set of vetted, tested and supported libraries and code templates. There is no need to run Cabal or other installers. The FP Application Server is used to deploy and run Haskell applications directly in the cloud. With many tutorials and sample code included in the product, FP Haskell Center provides both teachers and students with an accessible cloud-based platform to teach/learn, perform Haskell research, and develop real-world solutions. “Haskell was created at some leading universities in the world over 20 years ago and its advancement since then has been significantly driven by the global academic community,” said Aaron Contorer, FP Complete founder and CEO. “As Haskell becomes more mainstream, we want to provide the institutions championing Haskell the most the opportunity to keep it growing at no cost to them” he adds. “Great things are constantly coming out of the university setting and we want to support their research and projects as much as we can.” Eligible teachers and students can get a free account through a simple web sign-up form in mid-August, right before FP Haskell Center becomes generally available in early September. They can get started now by signing up <https://learning-site-staging.fpcomplete.com/business/designer-ide> for a Beta. Check for updates/details at www.fpcomplete.com. About FP Complete FP Complete is dedicated to bringing the Haskell programming language into the mainstream software market by being the leading developer of commercial Haskell software tools and services. Haskell is the new way to make software that accelerates time to market, boosts programmer productivity, lowers cost, and increases product quality. Haskell enables rapid development of high-performing, complex software with high quality, maintainability and scalability. Haskell has proven to be able to significantly cut the billions wasted in the compile- test-debugging-rework cycles where 50% of the software project costs are today. In short, Haskell delivers the competitive advantage and productivity that enterprises need in a global software-driven economy. Visit www.fpcomplete.com for more information. -- Natalia Muska Marketing Manager FP Complete, Inc. Natalia(a)fpcomplete.com 865-506-6513 skype: natalia.s.muska

1 0

Re: [Haskell-cafe] Proposal: Non-recursive let
by oleg＠okmij.org 25 Jul '13

25 Jul '13

ivan.chollet wrote: > let's consider the following: > > let fd = Unix.open ... > let fd = Unix.open ... > > At this point one file descriptor cannot be closed. Static analysis will > have trouble catching these bugs, so do humans. Both sentences express false propositions. The given code, if Haskell, does not open any file descriptors, so there is nothing to close. In the following OCaml code let fd = open_in "/tmp/a" in let fd = open_in "/tmp/v" in ... the first open channel becomes unreachable. When GC collects it (which will happen fairly soon, on a minor collection, because the channel died young), GC will finalize the channel and close its file descriptor. The corresponding Haskell code do h <- openFile ... h <- openFile ... works similarly to OCaml. Closing file handles upon GC is codified in the Haskell report because Lazy IO crucially depends on such behavior. If one is interested in statically tracking open file descriptors and making sure they are closed promptly, one could read large literature on this topic. Google search for monadic regions should be a good start. Some of the approaches are implemented and used in Haskell. Now about static analysis. Liveness analysis has no problem whatsoever determining that a variable fd in our examples has been shadowed and the corresponding value is dead. We are all familiar with liveness analysis -- it's the one responsible for `unused variable' warnings. The analysis is useful for many other things (e.g., if it determines that a created value dies within the function activation, the value could be allocated on stack rather than on heap.). Here is example from C: #include <stdio.h> void foo(void) { char x[4] = "abc"; /* Intentional copying! */ { char x[4] = "cde"; /* Intentional copying and shadowing */ x[0] = 'x'; printf("result %s\n",x); } } Pretty old GCC (4.2.1) had no trouble detecting the shadowing. With the optimization flag -O4, GCC acted on this knowledge. The generated assembly code reveals no traces of the string "abc", not even in the .rodata section of the code. The compiler determined the string is really unused and did not bother even compiling it in. > Disallowing variable shadowing prevents this. > The two "fd" occur in different contexts and should have different names. > Usage of shadowing is generally bad practice. It is error-prone. Hides > obnoxious bugs like file descriptors leaks. > The correct way is to give different variables that appear in different > contexts a different name, although this is arguably less convenient and > more verbose. CS would be better as science if we refrain from passing our personal opinions and prejudices as ``the correct way''. I can't say better than the user Kranar in a recent discussion on a similar `hot topic': The issue is that much of what we do as developers is simply based on anecdotal evidence, or statements made by so called "evangelicals" who blog about best practices and people believe them because of how articulate they are or the cache and prestige that the person carries. ... It's unfortunate that computer science is still advancing the same way medicine advanced with witch doctors, by simply trusting the wisest and oldest of the witch doctors without any actual empirical data, without any evidence, just based on the reputation and overall charisma or influence of certain bloggers or "big names" in the field. http://www.reddit.com/r/programming/comments/1iyp6v/is_there_a_really_an_em…

3 2

Re: [Haskell-cafe] Parsec question
by Kashyap CK 25 Jul '13

25 Jul '13

There is reference in the paper that empty list indicates failure...so could we just use it like Maybe? I'd like it very much if I could get an example of a missed match by not using the complete match. regards, Kashyap Sent from my Windows Phone From: Roman Cheplyaka Sent: 24/07/2013 8:19 PM To: C K Kashyap Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Parsec question Think about this: if you always take only the first element, why do you need lists at all? Roman * C K Kashyap <ckkashyap(a)gmail.com> [2013-07-24 19:56:29+0530] > Dear Cafe, > > I am trying to implement[1] parsec in go using the "Monadic Parser > Combinators" paper [2] . I've been able to implement "plus" "bind" and > "many" > While doing the implementation - I looked at bind closely > > bind :: Parser a -> (a -> Parser b) -> Parser b > p `bind` f = \inp -> concat [f v inp' | (v,inp') <- p inp] > > I wondered if the result needs the complete list - wouldn't just the first > successful value suffice? > Perhaps - > p `bind` f = \inp -> take 1 $ concat [f v inp' | (v,inp') <- p inp] > > Will this miss out matches? > > > Regards, > Kashyap > > [1] https://github.com/ckkashyap/parsec/blob/master/parsec.go > [2] Monadic Parser Combinators: Graham Hutton, Erik Meijer > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

3 2

Parsec question
by C K Kashyap 25 Jul '13

25 Jul '13

Dear Cafe, I am trying to implement[1] parsec in go using the "Monadic Parser Combinators" paper [2] . I've been able to implement "plus" "bind" and "many" While doing the implementation - I looked at bind closely bind :: Parser a -> (a -> Parser b) -> Parser b p `bind` f = \inp -> concat [f v inp' | (v,inp') <- p inp] I wondered if the result needs the complete list - wouldn't just the first successful value suffice? Perhaps - p `bind` f = \inp -> take 1 $ concat [f v inp' | (v,inp') <- p inp] Will this miss out matches? Regards, Kashyap [1] https://github.com/ckkashyap/parsec/blob/master/parsec.go [2] Monadic Parser Combinators: Graham Hutton, Erik Meijer

3 3

How can I use ghci more wisely?
by yi lu 25 Jul '13

25 Jul '13

I am wondering how can I ask ghci to show an infinite list wisely. When I type *fst ([1..],[1..10])* The result is what as you may guess *1,2,3,4,...*(continues to show, cut now) How could I may ghci show *[1..]* this wise way not the long long long list itself? Yi

6 6

Expression problem in the database?
by Manuel Gómez 24 Jul '13

24 Jul '13

Hi café, I don’t know whether this is a good forum to ask about this —perhaps Stack Overflow is better suited—, but since Haskell and related languages are so finely fit for good solutions to the expression problem, I figure this list may have a few helpful pointers regarding this problem. I’m facing a situation that requires saving boolean expressions of more or less arbitrary structure (encoding some business rules) into a SQL database. The expressions can include terms that refer to some other objects in the database. I realize this is somewhat vague, but that’s intentional: I’m really searching for ideas and experience with similar problems, not for a specific solution to my specific situation. Though I’m uncertain of their relative merits, I’ve had a few ideas myself: * I could sacrifice relational integrity and store the expression serialized, perhaps as an AST represented in JSON or somesuch — although the rest of the data model is a rather traditional, normalized relational schema, so this is undesirable in my situation if only for consistency. * I could directly model some form of the expression’s AST in the relational schema, and then endure the usual pain of representing sum types as relations. I imagine this to be quite unpleasant, although I haven’t tried it. * As these are boolean logic predicates, the expressions could be transformed into some normal form that could be more easily represented with relations. I’ll be mostly (but not exclusively) using this database from an application written in Haskell (Yesod using Esqueleto to talk to PostgreSQL), so some native Haskell solution could work almost as well as an SQL solution — but some legacy systems do need to interact with the database, so I’d prefer a solution in the database as long as it’s not horrible to work with in the application. I’ll be grateful for any ideas or pointers — my Googling for the expression problem has not proved fruitful. Thanks!

3 3

memoization
by Christopher Howard 24 Jul '13

24 Jul '13

When I previously asked about memoization, I got the impression that memoization is not something that just happens magically in Haskell. Yet, on a Haskell wiki page about Memoization <http://www.haskell.org/haskellwiki/Memoization#Memoization_with_recursion>, an example given is memoized_fib :: Int -> Integer memoized_fib = (map fib [0 ..] !!) where fib 0 = 0 fib 1 = 1 fib n = memoized_fib (n-2) + memoized_fib (n-1) I guess this works because, for example, I tried "memoized_fib 10000" and the interpreter took three or four seconds to calculate. But every subsequent call to "memoized_fib 10000" returns instantaneously (as does "memoized_fib 10001"). Could someone explain the technical details of why this works? Why is "map fib [0 ..]" not recalculated every time I call memoized_fib?

6 12

Expression problem in the database?
by oleg＠okmij.org 24 Jul '13

24 Jul '13

Here is one possible approach. First, convert the propositional formula into the conjunctive normal form (disjunctive will work just as well). Recall, the conjunctive normal form (CNF) is type CNF = [Clause] type Clause = [Literal] data Literal = Pos PropLetter | Neg PropLetter type PropLetter -- String or other representation for atomic propositions We assume that clauses in CNF are ordered and can be identified by natural indices. A CNF can be stored in the following table: CREATE DOMAIN PropLetter ... CREATE TYPE occurrence AS ( clause_number integer, (* index of a clause *) clause_card integer, (* number of literals in that clause *) positive boolean (* whether a positive or negative occ *) ); CREATE TABLE Formula ( prop_letter PropLetter references (table_of_properties), occurrences occurrence[] ); That is, for each prop letter we indicate which clause it occurs in (as a positive or a negative literal) and how many literals in that clause. The latter number (clause cardinality) can be factored out if we are orthodox. Since a letter may occur in many clauses, we use PostgreSQL arrays (which are now found in many DBMS). The formula can be evaluated incrementally: by fetching the rows one by one, keeping track of not yet decided clauses. We can stop as soon as we found a clause that evaluates to FALSE. BTW, `expression problem' typically refers to something else entirely (how to embed a language and be able to add more syntactic forms to the language and more evaluators without breaking previously written code).

1 0

Re: [Haskell-cafe] memoization
by wren ng thornton 24 Jul '13

24 Jul '13

On 7/22/13 7:41 PM, David Thomas wrote: > On Mon, Jul 22, 2013 at 4:04 PM, wren ng thornton <wren(a)freegeek.org> wrote: >> In principle, we could translate between these two forms (the f2 ==> f1 >> direction requires detecting that y does not depend on x). However, in >> practice, the compiler has no way to decide which one is better since it >> involves a space/time tradeoff which: (a) requires the language to keep >> track of space and time costs, (b) would require whole-program analysis to >> determine the total space/time costs, and (c) requires the user's >> objective function to know how to weight the tradeoff ratio. > > I, for one, would love to have a compiler do (a) based on (b), my > specification of (c), and the ability to pin particular things... Oh, so would I! But, having worked on this problem in a different language, I'm well aware of how difficult it is to actually implement (a) and (b). -- Live well, ~wren

1 0

CmdArgs non-flag arguments with newtypes
by Michael Orlitzky 24 Jul '13

24 Jul '13

I ran into an issue wrapping a [String] in a newtype with CmdArgs. You're supposed to be able to declare that a field contains a list of non-flag arguments... this works fine: data Cfg = Cfg { <whatever flags>, usernames :: [String] } arg_spec = Cfg { <whatever flags>, usernames = def &= args } ... If I now call my program with, ./foo --flag1 --flag2 arg1 arg2 then usernames = [ "arg1", "arg2" ] as desired. However, I need to wrap usernames in a newtype for an unrelated reason: newtype Usernames = Usernames [String] Now, CmdArgs unexpectedly drops the first non-flag argument. So, ./foo --flag1 --flag2 arg1 arg2 gives me usernames = [ "arg2" ]. Obviously not what I want! Has anyone else run into this? Figured out a workaround?

1 0