On Aug 9, 2004, at 5:00 PM, Simon Peyton-Jones wrote:
Closed classes are certainly interesting, but a better way to go in
this case is to allow the programmer to declear new kinds, as well as
new types. This is what Tim Sheard's language Omega lets you do, and
I'm considering adding it to GHC.
But that would break existing programs. You would need a language
extension so the feature could be selectively enabled.
Yes. Which means I think that you cannot support a closed world, as
given by that simple defining rule, without a language extension.
The root of the question seems to be
In my view without that simple defining
rule it is difficult to come up with a proposal that is simple,
I think I have decided that it was not really closed world I was
thinking of, but more along the lines of what Simon PJ posted...
After all at some point the compiler _has_ to commit to an
Just wondering, but what exacly is the problem with this open/closed stuff?
As far as I understand it new instances can be added to classes in Haskell
(because they are open)... But its not like instances can be added at link
time, and all the instances that you wish to be considered _must_ be
If the compiler treated instances as closed in this way, then adding a
new instance to the program could break existing parts of the program.
But there are many ways to do this... and besides this doesn't really make sense...
consider the following:
module A
defines class X
module B
PROTECTED] On Behalf Of MR
| K P SCHUPKE
| Sent: 12 August 2004 14:03
| To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
| Subject: Re: [Haskell-cafe] closed classes [was: Re: exceptions vs.
Either]
|
| Okay anybody whish to argue against these points:
|
| 1) closed or open is the same
On 12/08/2004, at 11:05 PM, Simon Peyton-Jones wrote:
module M where
class C a where
op :: a - a
instance C Int where
op x = x+1
f x = Just (op x)
Under your proposal, I'd infer f :: Int - Maybe Int, on the grounds
that C is closed and there is only one instance.
If I'm reading Keean's posts
:[EMAIL PROTECTED]
| Sent: 12 August 2004 14:52
| To: Simon Peyton-Jones
| Cc: MR K P SCHUPKE; [EMAIL PROTECTED]; [EMAIL PROTECTED]
| Subject: Re: [Haskell-cafe] closed classes [was: Re: exceptions vs. Either]
|
| On 12/08/2004, at 11:05 PM, Simon Peyton-Jones wrote:
|
| module M where
|
| class C
On Thu, Aug 12, 2004 at 06:37:20PM +0100, MR K P SCHUPKE wrote:
Surely it must be safe to assume a closed class at the top level?
This could be a source of unpleasant surprises, ie. something works
at top level, but breaks when you move it to some module. If by
top level you also mean Main (as
Informally, what I see as the defining rule for closed world is: an
expression is typed according to the set of definitions that are
visible in the context in which it is used. Other possibilities
exist, but the nice thing about this is that it is an extension of
what happens without overloading.
Notwithstanding module Y, I don't think you should infer in module X
that g::Int (or, rather, Int-Int). Since f is defined in a type class,
it should be polymorphic, and so should g. When you apply g to a type,
it will check to see what instances are available, and match only if Int
is the
Notwithstanding module Y, I don't think you should infer in module X
that g::Int (or, rather, Int-Int).
Oops, I meant Int-Int.
Since f is defined in a type class, it should be polymorphic, and so
should g. When you apply g to [an expression of a given] type, it
will check to see what
G'day all.
Quoting [EMAIL PROTECTED]:
Informally, what I see as the defining rule for closed world is: an
expression is typed according to the set of definitions that are
visible in the context in which it is used. Other possibilities
exist, but the nice thing about this is that it is an
Hi
On Mon, 9 Aug 2004, Simon Peyton-Jones wrote:
Closed classes are certainly interesting, but a better way to go in this
case is to allow the programmer to declear new kinds, as well as new
types. This is what Tim Sheard's language Omega lets you do, and I'm
considering adding it to GHC.
At the moment I'm only thinking of parameter-less kind declarations but
one could easily imagine kind parameters, and soon we'll have kind
polymorphism but one step at a time.
Any thoughts?
Apologies if it's widely known, but a system with kind polymorphism
was first considered by
kind statements sound like a good idea - a couple of questions spring to
mind - what is the parameter of a kind statement (a type or a kind... a
kind makes more sense) ... do we have to stop with kinds what about
kinds of kinds - the statement has identical syntax to a data declaration,
is there
Is there any possibility of a theory that will avoid the need to replicate
features at higher and higher levels?
If we consider types, types are a collection of values, for example we could
consider Int to be:
data Int = One | Two | Three | Four ...
Okay, so the values in an integer are
Simon Peyton-Jones wrote:
kind HNat = HZero | HSucc HNat
class HNatC (a::HNat)
instance HNatC HZero
instance HNatC n = HNatC (HSucc n)
There is no way to construct a value of type HZero, or (HSucc HZero);
these are simply phantom types. ... A merit of
On Fri, 2004-08-06 at 14:05, MR K P SCHUPKE wrote:
You should include the definitions of the classes before saying
HOrderedList l' just has to prove by induction that for any element
in the list, the next element is greater, so the class is simply:
class HOrderedList l
instance HNil
On Fri, 2004-08-06 at 15:44, Malcolm Wallace wrote:
Hmm...doesn't
--8--
module Closed(foo) where
class C a where foo = ...
instance C ...
--8--
module Main where
import Closed
...foo...
--8--
do what you want? You can only use
Malcolm Wallace [EMAIL PROTECTED] writes:
Ah, but now you cannot use (Closed t) = as a predicate in type
signatures, and since you cannot write a partial signature, you must
omit the signature altogether...
Hmm..yes, that would be a disadvantage. :-)
-ketil
--
If I haven't seen further, it
21 matches
Mail list logo
