I have

<pre>
*Main> \k -> k + 42
\k -> k + 42

<interactive>:1:0:
    No instance for (Show (a -> a))
      arising from a use of `print' at <interactive>:1:0-11
    Possible fix: add an instance declaration for (Show (a -> a))
    In a stmt of a 'do' expression: print it
</pre>

This is understandable, however, is there a way to define a 'show' for
lambdas?

instance Show (a -> b) where
  show _ = "Foo"

Greets
Ertugrul

Greets
Ertugrul

prompt> (lambda (x) x)
#<some printed representation of a function #x42>

This, IMHO opinion would be very useful.

If you're using GHCI and want to get information about an identifier,
just use :info or :type.

GHCI does store additional information, but this information is not
available in a compiled executable, so you cannot rely on its
availability inside the language itself (e.g., using Show).

In Haskell, one cannot compare functions for equality, one cannot
inspect them, one cannot change them. And that's done on purpose.

If you want to see the source code, just go look it up in the file.
Customize Emacs/your IDE if you do it often. Or use :list. GHCI is
fine for testing stuff and experiments, but don't use it as your main
developing environment. You need some kind of editor.

(defmethod pf ((f function)) (print f))

(pf (lambda (x) (+ x 42)))

If the above is in a file and I execute it (for an appropriate
definition of "execute") I will not get an error.  In Haskell I do and
it is just annoying.

I am sorry but I disagree with your take on the issue and I don't buy
your arguments.

If Haskell is a compiled language, why have ghci at all?  Once you
have an interpreter of sorts, the issue of printed representation of
anyhting does arise.  And, given that - rightly so - functions are
first class objects in Haskell, how do you "debug" a program?  At a
certain point, in some place you will have a function and your
debugger (which I have not tried - I will grant you that) will have to
show you what is in that place; hence the issue of a printed
representation of a function object does arise.  Moreover, why does
ghci prints 42 instead of XLII?

But, in any case, you are not making a convincing case that I should
not be able to just have

  foo x = do print (\k -> k + x + 1)
  main = foo 42

in a file, compile it and run it, just to have "something" printed
out.

Again, I do not care about comparing functions, nor inspecting their
code at runtime.  But this is not what I ask.  I ask that ghci did
something sensible, and - in general - that a derivation of Show
existed for arrow types.  I don't care about the format; I do not need
to use it in code.  But the error signaling is just plain annoying.

Having said that, I understand that this is simply not doable in the
language/implementation... as is.  Unless there were some deep typing
issues (of which I confess my ignorance) I just don't see why there
should not be a 'show' for function objects, at least in ghci.

  print "something"

instead, if you want "something" to appear on the screen.

The only printing you could do of functions that would give you any useful
information about the function is for a somehow enumerable domain, and
showable codomain, in which case you could write something like:

  instance (Enumerable a, Show a, Show b) => Show (a -> b) where
    show f = concatMap (\x -> show x ++ " |-> " ++ show f x ++ "\n")
                enumerate

Which for, say, not, will give you:

  False |-> True
  True |-> False

This is the only sort of showing that can be permitted, however, because any
representation produced based on the code, or pointers underlying the
implementation would violate either referential transparency or
extensionality, both of which are desirable formal properties for the
language to adhere to.

(And incidentally, the above Show instance violates the purpose of the Show
class, which is to produce valid Haskell code for the given value, such that
you could paste the string you get from 'show' into a source file, and get
back the same value you passed to 'show'. This isn't possible for functions
without compiler/interpreter magic, and as I mentioned above, it's ill-
advised compiler magic.)

Your complaint seems to center around wanting to type functions into GHCi
without getting errors that they aren't showable. But why do you want to do
that? Why is GHCi spitting out:

  This is a function.

[...]

The compiler and/or interpreter are not Haskell. There is no
metacircularity.

Prelude> let f x = x + 1
Prelude> :print f
f = (_t1::a -> a)

Again note, that is a feature of GHCI, and has nothing to do with
the Haskell language itself, and especially not the typeclass Show.
You can't do something like this in a standalone executable.

Haskell is *restrictive*. An attitude like "hey, I want it this way,
and I don't want to do it in another way, even if it's easily possible
in that other way" won't get you very far. If you fight the language,
instead of trying to understand how things are and why they are this
way, you won't have a lot of fun with Haskell. Your choice, of course.

Greets
Ertugrul

What's the point of this anyway?  In Haskell you get the error message
that there is no Show instance for whatever type your function might
have.  This is much more informative than printing something useless.

Really, what's the point of printing this stuff?

Greets
Ertugrul

As for the application, it is essentially for debugging reasons.  If
you don't see this fine.  I just think it would make life easier to
other people, like me.

At runtime, you can't even access the type of a function, because
types only exist at compile-time. What you can do is to use the types
at compile-time to insert additional information, with help of
typeclasses. Have a look at Data.Typeable for that. That's very
different from the :type command, which accesses additional information
that's stored in GHCI (and as such, not part of Haskell).

At runtime, you can't even access the type of a function, because
types only exist at compile-time. What you can do is to use the types
at compile-time to insert additional information, with help of
typeclasses. Have a look at Data.Typeable for that. That's very
different from the :type command, which accesses additional information
that's stored in GHCI (and as such, not part of Haskell).

  showIO :: a -> IO String

Next problem:  Semantically this showIO function doesn't make sense.  It
would be wrong to return anything useful about its argument.  To see why
this is a problem, try to implement a function of type a -> String.
This function cannot return anything meaningful.  In fact, this function
is either constant or undefined.

With access to the IO world, the showIO function doesn't have to be
constant, but it still cannot return anything useful about its argument.
Semantically it does not make sense.

As others have noted, the big type and function work of Haskell is done
at compile time.  That information is lost or scattered around the
entire executable file afterwards.  Functions get optimized away
entirely and may get moved around in memory.

Use the debugging capabilities of your interpreter.  You don't do the
debugging of your programs in your programs themselves.

Greets
Ertugrul

You asked a question, you got an answer. Don't like the answer? Tough,
because it's the correct answer, and any other answer isn't correct.
It's not as if you'll eventually get a different answer if you keep
asking.

        import Data.Typeable

        instance (Typeable a, Typeable b) => Show (a -> b) where
            show f = "#<function: " ++ show (typeOf f) ++ ">"

But this won't necessarily do what you expect, as any value occurring at
run-time must have a concrete type (i.e. you can't have a value of type
"a -> b"; both type variables must be instantiated). If you try using the
above in ghci, you'll get:

        *Main> \x -> x * x
        #<function: Integer -> Integer>

due to the default typing rules. OTOH, if you use it in a program, e.g.:

        f x = x * x

        main = do
            print f

you'll get a complaint about an ambiguous type variable.