Re: [Haskell-cafe] memoization
On Mon, Jul 22, 2013 at 04:04:33PM -0700, wren ng thornton wrote: Consider rather, f1 = let y = blah blah in \x - x + y f2 x = let y = blah blah in x + y The former will memoize y and share it across all invocations of f1; whereas f2 will recompute y for each invocation. Indeed. 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. This is called the full laziness transformation http://foldoc.org/full+laziness and indeed with optimization on GHC (sometimes) does it, even when not appropriate http://www.haskell.org/pipermail/haskell-cafe/2013-February/105201.html Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Expression problem in the database?
Hi Manuel, On 22 Jul 2013, at 21:00, Manuel Gómez wrote (with possible deletions): 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. [...] are you merely seeking for a relational encoding of Boolean expressions or do you plan to also operate on these expression (e.g., evaluate, simplify, normalize) inside the database? Cheers, --Torsten -- | Prof. Dr. Torsten Grust | Database Systems — Universität Tübingen (Germany) | torsten.gr...@uni-tuebingen.de | db.inf.uni-tuebingen.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Expression problem in the database?
On Tue, Jul 23, 2013 at 7:41 AM, Torsten Grust torsten.gr...@uni-tuebingen.de wrote: Hi Manuel, On 22 Jul 2013, at 21:00, Manuel Gómez wrote (with possible deletions): 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. [...] are you merely seeking for a relational encoding of Boolean expressions or do you plan to also operate on these expression (e.g., evaluate, simplify, normalize) inside the database? Not inside the database, no. I need to encode conditions for triggering actions in response to events when certain predicates are satisfied over properties of the event and other related objects in the database — but the rules would be manipulated and evaluated outside the database in the code that processes such events (specifically, in my situation, in response to requests to a REST service implemented with Yesod). The key issue is that terms in the expressions would refer to existing database objects, so even though the evaluation would happen outside the database, it’d be convenient to have referential integrity: if an expression states something like «the request is an order for red balloons or for a hot-wheels car, and the user who placed the order is from France», I’d much prefer to get a foreign key constraint violation error if the red balloons are removed from the database (or perhaps just let the database cascade the deletion into the rule, or whatever) than get an error at the time an order is placed and the code outside the database attempts to evaluate a rule that refers to some now nonexistent «red balloon» object. Again, I realize this is all rather vague and only tangentially related to the topic for this list — but I do imagine some here must have run into this sort of issue. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
On 22-7-2013 17:09, i c wrote:
On Wed, Jul 10, 2013 at 9:47 AM,o...@okmij.org wrote:
Jon Fairbairn wrote:
It just changes forgetting to use different variable names because of
recursion (which is currently uniform throughout the language) to
forgetting to use non recursive let instead of let.
Let me bring to the record the message I just wrote on Haskell-cafe
http://www.haskell.org/pipermail/haskell-cafe/2013-July/109116.html
and repeat the example:
In OCaml, I can (and often do) write
let (x,s) = foo 1 [] in
let (y,s) = bar x s in
let (z,s) = baz x y s in ...
In Haskell I'll have to uniquely number the s's:
let (x,s1) = foo 1 [] in
let (y,s2) = bar x s1 in
let (z,s3) = baz x y s2 in ...
and re-number them if I insert a new statement.
Not if you use pattern guards:
{-# LANGUAGE PatternGuards #-}
| ~(x,s) = foo 1 []
, ~(y,s) = bar x s
, ~(z,s) = baz x y s
= ...
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.
___
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] Proposal: Non-recursive let
| ~(x,s) = foo 1 [] , ~(y,s) = bar x s , ~(z,s) = baz x y s = ... in my previous message should be: | ~(x,s) - foo 1 [] , ~(y,s) - bar x s , ~(z,s) - baz x y s = ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ideas on a fast and tidy CSV library
Dear All, Recently I have been doing a lot of CSV processing. I initially tried to use the Data.Csv (cassava) library provided on Hackage, but I found this to still be too slow for my needs. In the meantime I have reverted to hacking something together in C, but I have been left wondering whether a tidy solution might be possible to implement in Haskell. I would like to build a library that satisfies the following: 1) Run a function f :: a_1 - ... - a_n - m (Maybe (b_1, ..., b_n)), with m some monad and the as and bs being input and output. 2) Be able to specify a maximum record string length and output record string length, so that the string buffers used for reading and outputting lines can be reused, preventing the need for allocating new strings for each record. 3) Allocate only once, the memory where the parsed input values, and output values are put. 4) The library's main function should take some kind of data structure describing the types of the function, the function itself and the filenames of input and output (could also be stdin/stdout). I am not sure yet what would be that best value of m. I would like to most importantly efficiently, and if possible, purely allow changes in state to a number of variables, such as an aggregation over a certain field in the input. I do not currently have knowledge of the FFI, and how it might be used in this case. I would appreciate any suggestions as to where I should look further. Regards, Justin Paston-Cooper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas on a fast and tidy CSV library
Justin Paston-Cooper paston.coo...@gmail.com writes: Dear All, Recently I have been doing a lot of CSV processing. I initially tried to use the Data.Csv (cassava) library provided on Hackage, but I found this to still be too slow for my needs. In the meantime I have reverted to hacking something together in C, but I have been left wondering whether a tidy solution might be possible to implement in Haskell. Have you tried profiling your cassava implementation? In my experience I've found it's quite quick. If you have an example of a slow path I'm sure Johan (cc'd) would like to know about it. I would like to build a library that satisfies the following: 1) Run a function f :: a_1 - ... - a_n - m (Maybe (b_1, ..., b_n)), with m some monad and the as and bs being input and output. 2) Be able to specify a maximum record string length and output record string length, so that the string buffers used for reading and outputting lines can be reused, preventing the need for allocating new strings for each record. 3) Allocate only once, the memory where the parsed input values, and output values are put. Ultimately this could be rather tricky to enforce. Haskell code generally does a lot of allocation and the RTS is well optimized to handle this. I've often found that trying to shoehorn a non-idiomatic optimal imperative approach into Haskell produces worse performance than the more readable, idiomatic approach. I understand this leaves many of your questions unanswered, but I'd give the idiomatic approach a bit more time before trying to coerce C into Haskell. Profile, see where the hotspots are and optimize appropriately. If the profile has you flummoxed, the lists and #haskell are always willing to help given the time. Cheers, - Ben pgpp3Fd9RzpaG.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
On 2013-07-22 17:09, i c wrote: Usage of shadowing is generally bad practice. It is error-prone. Hides obnoxious bugs like file descriptors leaks. These claims need to be substantiated, I think. (Not that I disagree, I just think that asserting this without evidence isn't going to convince anyone who is of the opposite mindset.) Regards, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
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. Disallowing variable shadowing prevents this. The two fd occur in different contexts and should have different names. On Tue, Jul 23, 2013 at 8:17 PM, Bardur Arantsson s...@scientician.netwrote: On 2013-07-22 17:09, i c wrote: Usage of shadowing is generally bad practice. It is error-prone. Hides obnoxious bugs like file descriptors leaks. These claims need to be substantiated, I think. (Not that I disagree, I just think that asserting this without evidence isn't going to convince anyone who is of the opposite mindset.) Regards, ___ 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] Proposal: Non-recursive let
It strikes me as unlikely static analysis would be confused by shadowing. On Tue, Jul 23, 2013 at 12:37 PM, i c ivan.chol...@gmail.com 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. Disallowing variable shadowing prevents this. The two fd occur in different contexts and should have different names. On Tue, Jul 23, 2013 at 8:17 PM, Bardur Arantsson s...@scientician.netwrote: On 2013-07-22 17:09, i c wrote: Usage of shadowing is generally bad practice. It is error-prone. Hides obnoxious bugs like file descriptors leaks. These claims need to be substantiated, I think. (Not that I disagree, I just think that asserting this without evidence isn't going to convince anyone who is of the opposite mindset.) Regards, ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ideas on a fast and tidy CSV library
On Tue, Jul 23, 2013 at 5:45 PM, Ben Gamari bgamari.f...@gmail.com wrote: Justin Paston-Cooper paston.coo...@gmail.com writes: Dear All, Recently I have been doing a lot of CSV processing. I initially tried to use the Data.Csv (cassava) library provided on Hackage, but I found this to still be too slow for my needs. In the meantime I have reverted to hacking something together in C, but I have been left wondering whether a tidy solution might be possible to implement in Haskell. Have you tried profiling your cassava implementation? In my experience I've found it's quite quick. If you have an example of a slow path I'm sure Johan (cc'd) would like to know about it. I'm always interested in examples of code that is not running fast enough. Send me a reproducible example (preferably as a bug on the GitHub bug tracker) and I'll take a look. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
quoth David Thomas davidleotho...@gmail.com, It strikes me as unlikely static analysis would be confused by shadowing. Not to mention that the example only created two expressions of type IO Fd? (I.e., no file descriptors were opened, let alone leaked.) But in any case, I would have guessed that the idea here is that much more than a few examples and counter-examples will be needed to validate something like `shadowing is bad.' If the assertion isn't too simplistic, the examples sure will be. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
On 2013-07-23 21:37, i c 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. Disallowing variable shadowing prevents this. The two fd occur in different contexts and should have different names. I think you've misunderstood my challenge. I'm not talking about examples of either good or bad, but empirical *evidence* for sample sizes greater than 1. As in: If there was an article title Is shadowing easier to understand than explicitly named intermediate variables? with an empirically supported conclusion, I think everybody would be happy, but I just don't think we're quite there... Regards, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
Static analysis is not confused by shadowing, it is confused by the file descriptor leak, which it can't find in the general case. Static analysis can only go as far as warning you that some variables are shadowed, and you will ignore such warning since you're doing variable shadowing purposely. This was what I meant by my comment. On Tue, Jul 23, 2013 at 9:02 PM, David Thomas davidleotho...@gmail.comwrote: It strikes me as unlikely static analysis would be confused by shadowing. On Tue, Jul 23, 2013 at 12:37 PM, i c ivan.chol...@gmail.com 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. Disallowing variable shadowing prevents this. The two fd occur in different contexts and should have different names. On Tue, Jul 23, 2013 at 8:17 PM, Bardur Arantsson s...@scientician.netwrote: On 2013-07-22 17:09, i c wrote: Usage of shadowing is generally bad practice. It is error-prone. Hides obnoxious bugs like file descriptors leaks. These claims need to be substantiated, I think. (Not that I disagree, I just think that asserting this without evidence isn't going to convince anyone who is of the opposite mindset.) Regards, ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] CmdArgs non-flag arguments with newtypes
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?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How can I use ghci more wisely?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] memoization
On 7/22/13 7:41 PM, David Thomas wrote: On Mon, Jul 22, 2013 at 4:04 PM, wren ng thornton w...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CmdArgs non-flag arguments with newtypes
On 7/23/13 9:01 PM, Michael Orlitzky wrote: Obviously not what I want! Has anyone else run into this? Figured out a workaround? I haven't run into this specific problem, but I do have a sort of workaround. Whenever dealing with CmdArgs (or any similar system) I typically define *two* record types. The first one just gets the raw input from CmdArgs; no more, no less. Thus, for your issue, this record would use String. For other issues mentioned recently about optionality, this record would use Maybe. The second one is the one actually used by the program as the configuration object. This one is generated from the first by performing various sanity checks, filling in defaults, converting types from their CmdArgs version to the version I actually want, etc. IME, regardless of language, trying to conflate these notions of an external-facing parser-state and an internal-facing configuration-record just causes problems and accidental complexity. It's best to keep them separate IMO. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I use ghci more wisely?
Knowing whether a computation will terminate is in general the halting problem, so immediately you're looking at a syntactic restriction. Here the only ones I can think of are artificial at best (i.e., they don't work for examples more than what you've shown here): http://trac.haskell.org/haskell-platform/ticket/180 There was some discussion [1] on putting a limit to what the interpreter prints out. Off the top of my head I suppose a hacky way to do this would be to define a new type deriving show in a way that printed out the list to some bounded depth. Kris [1] http://projects.haskell.org/pipermail/haskell-platform/2011-July/001619.html On Tue, Jul 23, 2013 at 10:30 PM, yi lu zhiwudazhanjiang...@gmail.com wrote: 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 ___ 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
[Haskell-cafe] Expression problem in the database?
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). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
