I read that Haskell will only remember the results of a call to a function if the function is in CAF (as opposed to being a lambda expression with variables).
I'm trying to rewrite some code in this form so that more of my functions become "memoized".
I was wondering: can all functions be written in CAF?
Let's say I had this function below, how would it look in CAF ?
f arg1 arg2 = map (\x-> someFunction x arg1 ) arg2submitted by asswaxer
[link] [8 comments]
There's so many FRP libs, and as someone totally new to the concept and wanting to learn, I don't even know enough to understand the differences. What do ordered, continuous and discrete mean? Do I want arrows or not? Is there a simple introduction to these concepts somewhere? Note that I am not asking which library to use, I found plenty of answers to that but it is all "I like Foo, use it". I am more interested in learning enough to answer the question for myself.submitted by I4dcQsEpLzTHvD1qhlDE
[link] [48 comments]
When I was a C++ programming, I got into template meta programming and it was awesome. I eventually realized that overdoing it can really make a mess.
Now, I gotten into GHC.Generics and TemplateHaskell and I'm loving it. I find that they can really simplify code nicely. In my current project, I find myself adding genetic code occasionally and I'm hoping that I'm not introducing maintenance nightmares for myself down the line. Does anyone have guidelines on when to avoid writing that kind of genetic code?submitted by cipher2048
[link] [13 comments]
The Scala language led me to Haskell, so here I am trying to learn it.
As a C++/C#/Python/Scala programmer I'm used to having full-featured IDEs.
I tried EclipseFP and Leksah on Windows 7 64-bit but they're both unusable, unfortunately. EclipseFP is very slow: characters are displayed seconds after I type them. For this reason, I tried Leksah but it keeps crashing when I try to debug my code (when I press CTRL+ENTER to evaluate an expression).
So, what should I do? Should I try VIM? I've never used anything so Linux-ish.submitted by Kiuhnm
[link] [105 comments]
Hello, I'm implementing a basic Knight's Tour path finder (Based on tuple list) and I think there should be a better way to write this, is there?:knightJump s a b = if (plausibleJump s a b (-1) (2)) /=  then plausibleJump s a b (-1) (2) else if (plausibleJump s a b (1) (2)) /=  then plausibleJump s a b (1) (2) else if (plausibleJump s a b (2) (1)) /=  then plausibleJump s a b (2) (1) else if (plausibleJump s a b (2) (-1)) /=  then plausibleJump s a b (2) (-1) else if (plausibleJump s a b (1) (-2)) /=  then plausibleJump s a b (1) (-2) else if (plausibleJump s a b (-1) (-2)) /=  then plausibleJump s a b (-1) (-2) else if (plausibleJump s a b (-2) (-1)) /=  then plausibleJump s a b (-2) (-1) else if (plausibleJump s a b (-2) (1)) /=  then plausibleJump s a b (-2) (1) else 
PS: I'm sorry if this is some kind of eye-hurtin haskell gore. Newbie heresubmitted by KomankK
[link] [11 comments]
Has anyone else faced this?
OS X Mavericks 10.9.5
ghci version -- 7.10.1
cabal -- 22.214.171.124
bash-3.2$ cabal install vector
Preprocessing library vector-0.10.12.3...
Data/Vector/Generic.hs:61:3: parse error on input ‘unsafeUpd’ Failed to install vector-0.10.12.3submitted by sriramalka
[link] [7 comments]
I've been wondering what makes code syntax in one programming language more readable / fun to write than others.
I wrote two ToDo apps in pseudo-code here: https://gist.github.com/everdev/275c8562e356b7f30c52
Would love your thoughts on which one feels more readable and would be more enjoyable to read/write and why. Thanks!submitted by everdev
[link] [7 comments]
Self-Representation in Girard’s System U, by Matt Brown and Jens Palsberg:
In 1991, Pfenning and Lee studied whether System F could support a typed self-interpreter. They concluded that typed self-representation for System F “seems to be impossible”, but were able to represent System F in Fω. Further, they found that the representation of Fω requires kind polymorphism, which is outside Fω. In 2009, Rendel, Ostermann and Hofer conjectured that the representation of kind-polymorphic terms would require another, higher form of polymorphism. Is this a case of infinite regress?
We show that it is not and present a typed self-representation for Girard’s System U, the first for a λ-calculus with decidable type checking. System U extends System Fω with kind polymorphic terms and types. We show that kind polymorphic types (i.e. types that depend on kinds) are sufficient to “tie the knot” – they enable representations of kind polymorphic terms without introducing another form of polymorphism. Our self-representation supports operations that iterate over a term, each of which can be applied to a representation of itself. We present three typed self-applicable operations: a self-interpreter that recovers a term from its representation, a predicate that tests the intensional structure of a term, and a typed continuation-passing-style (CPS) transformation – the first typed self-applicable CPS transformation. Our techniques could have applications from verifiably type-preserving metaprograms, to growable typed languages, to more efficient self-interpreters.
Typed self-representation has come up here on LtU in the past. I believe the best self-interpreter available prior to this work was a variant of Barry Jay's SF-calculus, covered in the paper Typed Self-Interpretation by Pattern Matching (and more fully developed in Structural Types for the Factorisation Calculus). These covered statically typed self-interpreters without resorting to undecidable type:type rules.
However, being combinator calculi, they're not very similar to most of our programming languages, and so self-interpretation was still an active problem. Enter Girard's System U, which features a more familiar type system with only kind * and kind-polymorphic types. However, System U is not strongly normalizing and is inconsistent as a logic. Whether self-interpretation can be achieved in a strongly normalizing language with decidable type checking is still an open problem.