On Tue, Sep 20, 2011 at 04:29:21PM -0700, J. Garrett Morris wrote:
> On Tue, Sep 20, 2011 at 3:44 PM, Simon Peyton-Jones
> wrote:
> > What should the GHCi command be *called*?
>
> :simplify or :simplifytype. In GHCi at the moment, you could abbreviate
> that as short as :si.
IMO Simon's suggest
On Wednesday 21 September 2011, 01:02:52, wagne...@seas.upenn.edu wrote:
> Would it be possible to have no command at all? Types are
> distinguished by upper-case letters, so it should be possible to tell
> whether a given expression is a value-level or a type-level expression.
Unless I'm misu
On Tue, Sep 20, 2011 at 3:44 PM, Simon Peyton-Jones
wrote:
> What should the GHCi command be *called*?
:simplify or :simplifytype. In GHCi at the moment, you could abbreviate
that as short as :si.
/g
--
"I’m surprised you haven’t got a little purple space dog, just to ram
home what an interg
type family Bar a :: *
type instance Bar () = String
data Foo a = Bar a | Baz a a
ghci> Bar ()
What happens?
There is a lot of ambiguity between term and type levels in Haskell.
(,); []; etc. It's only the overall structure of the language that
disambiguates them; you can't necessarily tell jus
Would it be possible to have no command at all? Types are
distinguished by upper-case letters, so it should be possible to tell
whether a given expression is a value-level or a type-level expression.
I guess that's not strictly true, since the expression could be _only_
type variables -- bu
Sean
Yes, this has been asked for before, and it wouldn't be hard to implement.
What should the GHCi command be *called*?
We already have :kind, which displays the kind of a type. Maybe :kind! should
evaluate the type as well? Or perhaps :kind should evaluate anyway (although
that would be
I would like to ask GHCi for the type that a type expression will evaluate
to, once all definitions of type synonyms and (when possible) type families
have been inlined.
It appears that I can do some part of this for type T by using ":t undefined
:: T":
type family F a
type instance F Int = Bool
This is (a) one of the big advantages of records and (b) why it's a mistake to
have the record discussion without taking into account some notion of lens.
Haskell field names are a red herring because they're selector functions - what
we need is a record system which generates lenses and solves
