On 2/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> It seems we can emulate the restricted data types in existing
> Haskell.
I have proposed this for Haskell' libraries. See
http://hackage.haskell.org/trac/haskell-
On 2/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> It seems we can emulate the restricted data types in existing
> Haskell.
...
> > {-# OPTIONS -fglasgow-exts #-}
> > {-# OPTIONS -fallow-undecidable-instances #-}
http://article.gmane.org/gmane.comp.lang.haskell.
Hello Jan-Willem,
Wednesday, February 08, 2006, 4:26:48 PM, you wrote:
JWM> Should there be a class which is implemented by every well-formed
JWM> type of kind (*)? Should that class have one or more of the following:
JWM>* Structural decomposition and reconstruction a la Generics?
JWM>*
On Feb 7, 2006, at 11:45 PM, John Meacham wrote:
Ashley Yakeley has convinced me this proposal won't work as is. I knew
that dropping of the a type parameter in the dictionary passing scheme
would bite me :). though, perhaps it will inspire another proposal? In
the meantime, I will see about im
Hello Simon,
Tuesday, February 07, 2006, 7:36:23 PM, you wrote:
SPJ> | data Eq a => Set a = Set (List a)
SPJ> |
SPJ> | that is a sort of extension i will be glad to see. in my Streams
SPJ> | library, it's a typical beast and i forced to move all these contexts
SPJ> | to the instances/functions d
It seems we can emulate the restricted data types in existing
Haskell. The emulation is good enough to run the examples recently
suggested on this list. So, we can start gaining experience with the
feature.
The emulation involves a slight generalization of the Monad class --
something that also
In article <[EMAIL PROTECTED]>,
John Meacham <[EMAIL PROTECTED]> wrote:
> Ah. I think I see the objection now. Will have to think about it some.
Here's a simpler example:
class HasInt a where
getInt :: a -> Int
instance HasInt Int where
getInt = id
newtype HasInt a => T a = T
Ashley Yakeley has convinced me this proposal won't work as is. I knew
that dropping of the a type parameter in the dictionary passing scheme
would bite me :). though, perhaps it will inspire another proposal? In
the meantime, I will see about implementing the 'wft' constraints as
mentioned in the
Ah. I think I see the objection now. Will have to think about it some.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
I'll give the full desugaring, perhaps that will make it more clear:
> foo :: (Monad m) => m Int
> foo = return id >>= (\i -> return (i 7))
>
> fooSet :: Set Int
> fooSet = foo
mkMonadDictSet :: EqDict a -> MonadDict Set
eqDictInt :: EqDict Int
return :: MoandDict m -> a -> m a
foo :: Mona
On Tue, Feb 07, 2006 at 07:59:46PM -0800, Ashley Yakeley wrote:
> John Meacham wrote:
>
> >however, (Set (a -> a)) is malformed. since a _requirement_ is that Set
> >can only be applied to a type with an Eq constraint so the instance you
> >try to do something like
> >
> >returnid :: Set (a -> a)
John Meacham wrote:
however, (Set (a -> a)) is malformed. since a _requirement_ is that Set
can only be applied to a type with an Eq constraint so the instance you
try to do something like
returnid :: Set (a -> a) -- ^ static error! you need
returnid :: Eq (a -> a) => Set (a -> a)
the instant
On Tue, Feb 07, 2006 at 05:54:51PM -0800, Ashley Yakeley wrote:
> John Meacham wrote:
>
> >newtype Eq a => Set a = Set (List a)
> >singleton :: Eq a => a -> Set a
> >class Monad m where
> >return :: a -> m a
> >
> >instance Monad Set where
> >return x = singleton x
> >
> >okay, our
John Meacham wrote:
newtype Eq a => Set a = Set (List a)
singleton :: Eq a => a -> Set a
class Monad m where
return :: a -> m a
instance Monad Set where
return x = singleton x
okay, our goal is to make this typesafe.
You shouldn't be able to, should you? Monad makes a promis
et's see...
>
> data Eq a => Set a = ...
>
> uniq :: Eq a => [a] -> [a]
> uniq =
>
> Now if Set switches to an Ord implementation, I will suddenly have a
> problem...
indeed, but restricted data types wern't meant to protect against this
sort of thing
I am trying to reformulate restricted data types such that they can
easily be implemented by jhc and possibly standardized independent of
the implementation method and would like to run what I have so far by
the list. Unlike the original paper, I will treat the user-visible
changes to the type
On 2/7/06, John Meacham <[EMAIL PROTECTED]> wrote:
> But this is exactly the behavior you want, you can't very well expect to
> sort without an Ord a instance.
Okay, so maybe that was a bad example. Let's see...
data Eq a => Set a = ...
uniq :: Eq a => [a] -> [a]
uniq =
Now if Set switches to
On Tue, Feb 07, 2006 at 06:38:25PM -0600, Taral wrote:
> On 2/5/06, Jim Apple <[EMAIL PROTECTED]> wrote:
> > Have we considered Restricted Data Types?
> >
> > http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
> >
> > Or even absracting over c
On 2/5/06, Jim Apple <[EMAIL PROTECTED]> wrote:
> Have we considered Restricted Data Types?
>
> http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
>
> Or even absracting over contexts, as described in section 7.5 (p.
> 14/15) of the above?
I've discove
Simon Peyton-Jones wrote:
Another reasonable alternative is
data Set a = Eq a => Set (List a)
The type of member would become
member :: a -> Set a -> Bool
(with no Eq constraint).
John Hughes mentions this in section 5.2 of the paper, and points out a
problem: a function like
John Hughes wrote:
> That means that the Monad class is not allowed to declare
>
>return :: a -> m a
>
> because there's no guarantee that the type m a would be well-formed. The
> type declared for return has to become
>
>return :: wft (m a) => a -> m a
I'm c
Simon Peyton-Jones wrote:
| >> Have we considered Restricted Data Types?
| >>
| >> http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
| >
|
| Finally, I wrote my paper before fundeps came on the scene. Some of
the contortions I went through
| in my simula
t; Eq a available in here... }
I am not sure whether it would address all of the cases in John's paper,
but it'd address some of them.
It would be a significantly less radical step than Restricted Data Types
I think. In particular, with GADTs imagine:
data T where
| >> Have we considered Restricted Data Types?
| >>
| >> http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
| >
|
| Finally, I wrote my paper before fundeps came on the scene. Some of
the contortions I went through
| in my simulation of RDTs could be avoided wit
John Hughes wrote:
That means that the Monad class is not allowed to declare
return :: a -> m a
because there's no guarantee that the type m a would be well-formed. The
type declared for return has to become
return :: wft (m a) => a -> m a
I'm confused. It seems like the type (a -> m
From: John Meacham <[EMAIL PROTECTED]>
Subject: Re: Restricted Data Types
however, what prevents the following from being _infered_
return Foo :: Moand m => m Foo
so, we think we can specialize it to
return Foo :: Set Foo
however, we no longer have the constraint that Foo must
On 2/5/06, Jim Apple <[EMAIL PROTECTED]> wrote:
Have we considered Restricted Data Types?
http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
Nice to see my old paper hasn't sunk without trace!
As Taral pointed out, though, Restricted Data Types have not been implem
Hello John,
Tuesday, February 07, 2006, 4:23:36 AM, you wrote:
data Eq a => Set a = Set (List a)
that is a sort of extension i will be glad to see. in my Streams
library, it's a typical beast and i forced to move all these contexts
to the instances/functions definitions:
data BufferedMemoryStre
pe? :-)
Funny you should mention that, I was looking into it last night and in
fact, yes, restricted data types are dead trivial to implement in jhc.
The _only_ thing that needs to be done is to modify the type checker
such that it accepts the instances it would have rejected earlier and
nothing ab
On 2/5/06, Jim Apple <[EMAIL PROTECTED]> wrote:
> Have we considered Restricted Data Types?
>
> http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
You know, when I first used datatypes with context, I expected it to
work this way, and was very surprised that it didn
Jim Apple wrote:
Have we considered Restricted Data Types?
http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
I'd never seen this paper before. This would be a really nice extension to
have. The dictionary wrangling looks nasty, but I think it would be easy to
implement
Have we considered Restricted Data Types?
http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
Or even absracting over contexts, as described in section 7.5 (p.
14/15) of the above?
Jim
___
Haskell-prime mailing list
Haskell-prime
32 matches
Mail list logo
