Ian Lynagh wrote:
On Fri, Sep 26, 2008 at 06:25:53PM +0100, Simon Peyton-Jones wrote:
|
| But then you wouldn't be able to write the current meaning of
| Chan (Int ? Bool ! Emp)
| with infix type variables.
I am proposing a *change* from current behavior
I realise that, I'm just not convi
Manuel M T Chakravarty wrote:
Ian Lynagh:
On Fri, Sep 26, 2008 at 06:25:53PM +0100, Simon Peyton-Jones wrote:
|
| But then you wouldn't be able to write the current meaning of
| Chan (Int ? Bool ! Emp)
| with infix type variables.
I am proposing a *change* from current behavior
I realise
Ian Lynagh:
On Fri, Sep 26, 2008 at 06:25:53PM +0100, Simon Peyton-Jones wrote:
|
| But then you wouldn't be able to write the current meaning of
| Chan (Int ? Bool ! Emp)
| with infix type variables.
I am proposing a *change* from current behavior
I realise that, I'm just not convinced t
| I'd have thought that good infix syntax was more important for data
| constructors than type constructors, and we manage with a : prefix for
| data constructors.
It'd be nice at the term level too. But we don't have that choice for data
constructors, whereas we do for types. People very seldo
Ian Lynagh:
On Tue, Sep 23, 2008 at 11:57:24PM +0200, Sean Leather wrote:
I've written down the issues and made some proposals here.
http://hackage.haskell.org/trac/ghc/wiki/Design/TypeNaming
What purpose does the "type" disambiguating specifier serve in
proposal 1?
Don't type synonyms have
On Fri, Sep 26, 2008 at 06:25:53PM +0100, Simon Peyton-Jones wrote:
> |
> | But then you wouldn't be able to write the current meaning of
> | Chan (Int ? Bool ! Emp)
> | with infix type variables.
>
> I am proposing a *change* from current behavior
I realise that, I'm just not convinced that
| > I don't want this discussion to get out of control! All I'm after is a way
| to make (+) into a type constructor, which I think is highly desirable
| notationally. We saw another instance yesterday, when Dov was writing session
| types like (Chan (Int :?: Bool :?: Emp)) when he should have bee
On Fri, Sep 26, 2008 at 04:31:23PM +0100, Simon Peyton-Jones wrote:
> | > Arguably we should drop the upper/lower case distinction altogether, on
> | > the grounds that some (written) languages don't even have it. That
> | > would solve this problem and restore unity, but it's a much bigger
> | >
| > Arguably we should drop the upper/lower case distinction altogether, on
| > the grounds that some (written) languages don't even have it. That
| > would solve this problem and restore unity, but it's a much bigger
| > change and has other disadvantages.
|
| I was suggesting that this change sh
> | Incidentally, it might be worth breaking proposal 1 into two separate
> | proposals: It would be useful to be able to disambiguate imports/exports
> | even if we don't change the lexical rules for types, as it would allow
> | the class and type namespaces to be separated.
>
> I don't advocate s
| > What purpose does the "type" disambiguating specifier serve in proposal 1?
| > Don't type synonyms have the same namespace as datatypes? It would make
| > sense to me to match (export specifier<->declaration) data<->data,
| > newtype<->newtype, and type<->type for explicit documentation purpose
On Thu, Sep 25, 2008 at 01:05:29PM +0100, Simon Marlow wrote:
>
> As I understand it, (+) would be syntactically a type constructor, not a
> type variable.
>
> > I'm not really convinced that there should be different rules for the
> > value and type levels, though.
>
> Arguably we should drop t
Ian Lynagh wrote:
On Tue, Sep 23, 2008 at 11:57:24PM +0200, Sean Leather wrote:
I've written down the issues and made some proposals here.
http://hackage.haskell.org/trac/ghc/wiki/Design/TypeNaming
What purpose does the "type" disambiguating specifier serve in proposal 1?
Don't type synonyms ha
On Tue, Sep 23, 2008 at 11:57:24PM +0200, Sean Leather wrote:
> >
> > I've written down the issues and made some proposals here.
> > http://hackage.haskell.org/trac/ghc/wiki/Design/TypeNaming
>
> What purpose does the "type" disambiguating specifier serve in proposal 1?
> Don't type synonyms have
Simon Peyton-Jones wrote:
As we push the boundary on Haskell’s type system, so that types and
values blur a bit more, Haskell’s deliberate overlapping of type
constructor and data constructor name space is becoming a little
awkward. Syntax is tiresome, but it’s unavoidable.
I’ve written dow
> As we push the boundary on Haskell's type system, so that types and values
> blur a bit more, Haskell's deliberate overlapping of type constructor and
> data constructor name space is becoming a little awkward. Syntax is
> tiresome, but it's unavoidable.
>
> I've written down the issues and mad
16 matches
Mail list logo
