Sorry I screwed up. The following is indeed memoizing:
fib5 :: Int - Integer
fib5 = \ x - fibs !! x
where fibs = map fib [0 ..]
fib 0 = 0
fib 1 = 1
fib n = fib5 (n-2) + fib5 (n-1)
Here, the eta-expansion does not matter. But as you say, memoized_fib
below is not
On 23.07.13 4:34 AM, Richard A. O'Keefe wrote:
On 22/07/2013, at 8:14 PM, Andreas Abel wrote:
Just today, my student asked me why the following program does nothing:
Did you ask your student why their code should not be torn into pieces,
burned to ashes, and incorporated into a pot for
Sure. I have not looked a concrete strictness analyses, but I expect
they would treat Conat differently than Integer. In particular,
x does *not* appear strictly in S x
if S is a lazy constructor.
On 22.07.13 4:54 PM, Edward Kmett wrote:
let x = x +1
is perfectly cromulent when x is
This portion of haskell-mode (haskell-interactive-mode-eval-pretty) is what
the UI for something like this could look like:
https://www.youtube.com/watch?v=pu9AGSOySlE
This isn't an answer to your question, though, because expanding subparts
of the output doesn't drive evaluation. It would be
On Wed, Jul 24, 2013 at 10:06:59AM +0200, Andreas Abel wrote:
For -O1 and greater, ghc seems to see that x is not mentioned in the
where clauses and apparently lifts them out. Thus, for -O1..
memoized_fib is also memoizing. (I ran it, this time ;-) !)
Right, I believe this is the full
Hi,
Am Mittwoch, den 24.07.2013, 01:41 -0700 schrieb Michael Sloan:
Another non-answer is to take a look at using vaccum[0] and
vaccum-graphviz[1] together, to get an idea of the heap structure of
unforced values. I've made a gist demonstrating how to use these to
visualize the heap without
The data-pprint package's pprint function might give you a quick fix.
For example:
Prelude :m Data.PPrint
Prelude Data.PPrint pprint [1..]
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36,
37, 38, 39, 40, 41,
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' |
Think about this: if you always take only the first element, why do you
need lists at all?
Roman
* C K Kashyap ckkash...@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
On Mon, Jul 22, 2013 at 4:00 PM, Manuel Gómez tar...@gmail.com wrote:
* 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,
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
You only have a Num constraint when type checking that code:
(+) :: Num a = a - a - a
For better or worse, you don't get strictness in the type signatures in
Haskell.
We do not separate codata from data here.
Without knowing about the particular instance of Num and even the direction
of
Because of laziness, you do in a sense only take the first successful
value. When I've made parser combinators for Python before, I've used
either generators or exceptions to get lazy evaluation, since computing the
whole list of possibilities for each bind would ruin the running time of
the
You might like to know about this option for ghci -interactive-print
I tested it with data-pprint though and it didn't work because it
returns an IO Doc instead of IO () (I assume). But if you wrote a
function that used that, returned the right type, cabal installed it
and put it in your .ghci,
To construct such an example, you have to ask yourself: when can we get a
list of more than one element?
Consider this:
a = char 'a'
((a a) | a) a
Suppose that our input is aa. The result of ((a a) | a) would be
the list
[('a', ), ('a', a)]
If you proceed with the first element of
Thanks for the tip, David, I didn't know about that flag! Looks
really handy for playing with EDSLs, which is usually better off
displayed through Doc, but the default Show instance is indispensable
when I find a bug in the conversion to the Doc.
Unfortunately, though, I'd be reluctant to make
Hello all,
This should be simple, and I thought it had it working, but I've broken it and
can't figure out why.
What I want is to invoke the callback whenever the user activates and entry in
a dialogbox, so I did both this :
Gtk.on entry Gtk.entryActivate (boxHandler entry)
(I believe this
Thanks Kyle,
My initial implementation was evaluating the whole list - the current one
though just returns the first successful result. Anyway, I think I need the
backtracking - I would want the aaa as the result :)
I will now explore using go-routines to implement laziness.
Thank you so much
Thanks Roman .. I'll try and implement laziness to retain the whole list.
Regards,
Kashyap
On Thu, Jul 25, 2013 at 3:41 AM, Roman Cheplyaka r...@ro-che.info wrote:
To construct such an example, you have to ask yourself: when can we get a
list of more than one element?
Consider this:
a =
19 matches
Mail list logo
