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.
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
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
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
| ~(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
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
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
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
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
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
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
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
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
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.
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 }
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
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
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
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):
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
20 matches
Mail list logo
