jerzy karczmarczuk wrote:
apfelmus:
As Feynman put it: "What do you care what other people think?"
It was not Feynman, but his wife.
Thanks, I should have questioned my claim :)
Regards,
apfelmus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskel
apfelmus:
As Feynman put it: "What do you care what other people think?"
It was not Feynman, but his wife.
Jerzy Karczmarczuk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Dan Weston wrote:
Questioning apfelmus definitely gives me pause, but...
Don't hesitate! :) Personally, I question everyone and everything,
including myself. This is a marvelous protection against unintentionally
believing things just because I've heard them several times like "Monads
are ha
On 10 Dec 2007, at 11:33 AM, Dan Weston wrote:
Questioning apfelmus definitely gives me pause, but...
> id :: a -> a-- "arity" 1
> id = ($) :: (a -> b) -> (a -> b) -- "arity" 2
I agree with the arities given above (but without quotes) and see
no ill-definedness to
Questioning apfelmus definitely gives me pause, but...
> id :: a -> a-- "arity" 1
> id = ($) :: (a -> b) -> (a -> b) -- "arity" 2
I agree with the arities given above (but without quotes) and see no
ill-definedness to arity.
But these are two different classes of fu
On 7 Dec 2007, at 12:39 PM, Dan Weston wrote:
Luke Palmer wrote:
On Dec 7, 2007 7:57 PM, Luke Palmer <[EMAIL PROTECTED]> wrote:
On Dec 7, 2007 7:41 PM, Dan Weston <[EMAIL PROTECTED]> wrote:
Luke Palmer wrote:
You can project the compile time numbers into runtime ones:
Yes, that works well if
Luke Palmer wrote:
Hmm, this still seems ill-defined to me.
compose :: (Int -> Int -> Int) -> (Int -> Int) -> Int -> Int -> Int
Is a valid expression given that definition (with a,b = Int and c = Int -> Int),
but now the arity is 4.
That's correct, the arity of a function is not well-defined
On Dec 7, 2007 8:39 PM, Dan Weston <[EMAIL PROTECTED]> wrote:
> > compose f g = f . g
> >
> > compose' f g x = f (g x)
> >
> > Are you saying that these two exactly equivalent functions should have
> > different arity? If not, then is the arity 2 or 3?
>
> Prelude> :t let compose f g = f . g in c
Luke Palmer wrote:
On Dec 7, 2007 7:57 PM, Luke Palmer <[EMAIL PROTECTED]> wrote:
On Dec 7, 2007 7:41 PM, Dan Weston <[EMAIL PROTECTED]> wrote:
Luke Palmer wrote:
You can project the compile time numbers into runtime ones:
Yes, that works well if I know a priori what the arity of the function
On Dec 7, 2007 7:57 PM, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On Dec 7, 2007 7:41 PM, Dan Weston <[EMAIL PROTECTED]> wrote:
> > Luke Palmer wrote:
> > > You can project the compile time numbers into runtime ones:
> >
> > Yes, that works well if I know a priori what the arity of the function
> >
On Dec 7, 2007 7:41 PM, Dan Weston <[EMAIL PROTECTED]> wrote:
> Luke Palmer wrote:
> > You can project the compile time numbers into runtime ones:
>
> Yes, that works well if I know a priori what the arity of the function
> is. But I want to be able to have the compiler deduce the arity of the
> fu
Luke Palmer wrote:
You can project the compile time numbers into runtime ones:
Yes, that works well if I know a priori what the arity of the function
is. But I want to be able to have the compiler deduce the arity of the
function (e.g. by applying undefined until it is no longer a function),
On Dec 7, 2007 6:21 PM, Dan Weston <[EMAIL PROTECTED]> wrote:
> This is great! Two questions:
>
> 1) I want to make sure the function arity matches the list length (as a
> runtime check). I think I can do this with an arity function using
> Data.Typeable. I came up with:
>
> arity f = a (typeOf f)
This is great! Two questions:
1) I want to make sure the function arity matches the list length (as a
runtime check). I think I can do this with an arity function using
Data.Typeable. I came up with:
arity f = a (typeOf f) where
a tr | typeRepTyCon tr /= mkTyCon "->" = 0
| otherwise
On Dec 7, 2007 4:46 PM, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On Dec 7, 2007 6:27 AM, Victor Nazarov <[EMAIL PROTECTED]> wrote:
> >
> > nary 0 x [] = x
> > nary n f (x:xs) | n > 0 = nary (n-1) (f $ read x) xs
>
> Sometimes it helps to write type signatures for functions. As in this
> case, wher
On Dec 7, 2007 6:27 AM, Victor Nazarov <[EMAIL PROTECTED]> wrote:
> Cool solution and not so complicated and ad-hoc. But I'd like to ask
> isn't the following definition is more natural and simple?
>
> nary 0 x [] = x
> nary n f (x:xs) | n > 0 = nary (n-1) (f $ read x) xs
Sometimes it helps to wri
On Dec 7, 2007 2:52 PM, <[EMAIL PROTECTED]> wrote:
>
> In fact, that distinction is possible. The following article
>
> How to write an instance for not-a-function
> http://okmij.org/ftp/Haskell/typecast.html#is-function-type
>
> specifically describes a method of writing an instan
Philipp N. wrote:
> i'm trying to wrap functions (a -> b -> ... -> z) of any arity to functions
> of type ([String] -> y), where list of strings replaces the typed arguments.
> the problem is, that you cannot distinguish type (x->y) from z, so these
> instances are overlapping.
to which apfelmus
Philipp N. wrote:
i'm trying to wrap functions (a -> b -> ... -> z) of any arity to functions
of type ([String] -> y), where list of strings replaces the typed arguments.
one attempt looks like this (here written with type families, you can
replace it by functional dependencies or what ever):
19 matches
Mail list logo
