On Wed, Jul 11, 2007 at 11:14:20AM +0100, Tony Finch wrote:
> registers or on the stack) and a case analysis branch, but a normal
> function return (predictable by the CPU) is replaced by a less-predictable
> indirect jump. Does anyone have references to a paper that discusses an
GHC does not use
On 7/11/07, Tony Finch <[EMAIL PROTECTED]> wrote:
Does anyone have references to a paper that discusses an
optimisation like this for any language, not just Haskell?
Section 4.8 of "Implementing lazy functional languages on stock
hardware: the Spineless Tagless G-machine." by Simon Peyton Jones
I've recently been wondering (in a more general context than just haskell)
about optimisations along the lines of
foo x y z = if complicated thing then Cons1 a b c
else if other complicated thing then Cons2 d e
else Cons3 f
bar some args = case foo perhaps different args o
Thanks for the explanations - fully understood.
Tony Morris
http://tmorris.net/
Jonathan Cast wrote:
> On Tuesday 10 July 2007, Tony Morris wrote:
>> Thanks Don,
>> Is your explanation specific to maybe? Or does that apply to all functions?
>>
>> Suppose the following function for lists:
>>
>>
On Tuesday 10 July 2007, Nicolas Frisby wrote:
> This might be a feasible appropriation of the term "destructor".
Co-constructor?
Jonathan Cast
http://sourceforge.net/projects/fid-core
http://sourceforge.net/projects/fid-emacs
___
Haskell-Cafe mailing
This might be a feasible appropriation of the term "destructor".
On 7/10/07, Bruno Oliveira <[EMAIL PROTECTED]> wrote:
On Tue, 10 Jul 2007 10:53:35 +0200 (MEST), Henning Thielemann wrote:
>On Tue, 10 Jul 2007, Tony Morris wrote:
>A foldr without recursion. I use such functions frequently in orde
On Tuesday 10 July 2007, Tony Morris wrote:
> Thanks Don,
> Is your explanation specific to maybe? Or does that apply to all functions?
>
> Suppose the following function for lists:
>
> f :: [a] -> b -> (a -> [a] -> b) -> b
>
> ...instead of pattern matching [] and (x:xs)
Of course. GHC doesn't k
Hello,
On Tue, 10 Jul 2007 10:53:35 +0200 (MEST), Henning Thielemann wrote:
>On Tue, 10 Jul 2007, Tony Morris wrote:
>> Is your explanation specific to maybe? Or does that apply to all functions?
>>
>> Suppose the following function for lists:
>>
>> f :: [a] -> b -> (a -> [a] -> b) -> b
>>
>> .
On Tue, 10 Jul 2007, Donald Bruce Stewart wrote:
> lemming:
> >
> > On Tue, 10 Jul 2007, Tony Morris wrote:
> >
> > > Is your explanation specific to maybe? Or does that apply to all
> > > functions?
> > >
> > > Suppose the following function for lists:
> > >
> > > f :: [a] -> b -> (a -> [a] ->
lemming:
>
> On Tue, 10 Jul 2007, Tony Morris wrote:
>
> > Is your explanation specific to maybe? Or does that apply to all functions?
> >
> > Suppose the following function for lists:
> >
> > f :: [a] -> b -> (a -> [a] -> b) -> b
> >
> > ...instead of pattern matching [] and (x:xs)
>
> A foldr
tmorris:
> Thanks Don,
> Is your explanation specific to maybe? Or does that apply to all functions?
>
> Suppose the following function for lists:
>
> f :: [a] -> b -> (a -> [a] -> b) -> b
>
> ...instead of pattern matching [] and (x:xs)
It really depends on the body of 'f'. If they're simple w
On Tue, 10 Jul 2007, Tony Morris wrote:
> Is your explanation specific to maybe? Or does that apply to all functions?
>
> Suppose the following function for lists:
>
> f :: [a] -> b -> (a -> [a] -> b) -> b
>
> ...instead of pattern matching [] and (x:xs)
A foldr without recursion. I use such fun
Thanks Don,
Is your explanation specific to maybe? Or does that apply to all functions?
Suppose the following function for lists:
f :: [a] -> b -> (a -> [a] -> b) -> b
...instead of pattern matching [] and (x:xs)
Tony Morris
http://tmorris.net/
Donald Bruce Stewart wrote:
> tmorris:
>> When
tmorris:
> When you you use maybe :: b -> (a -> b) -> Maybe a -> b instead of
> pattern matching a returned Maybe value?
>
> Is there something a bit more concrete on this issue?
You mean, versus using 'case' or sugar for case?
It'll just inline to the same code.
For example:
maybe 10 (\n -
Is there a performance penalty to be paid when using CPS instead of
pattern matching? CPS often "feels more concise" but I suspect that it
incurs a cost because of the accumulating stack that pattern matching
wouldn't.
When you you use maybe :: b -> (a -> b) -> Maybe a -> b instead of
pattern matc
15 matches
Mail list logo
