Anthony
You may be interested in Carlos Camarao’s interesting work. For a long time
now he has advocated (in effect) making each function into its own type class,
rather that grouping them into classes. Perhaps that is in line with your
thinking.
https://homepages.dcc.ufmg.br/~camarao/
October 2018 02:52
| To: Simon Peyton Jones ; haskell-prime@haskell.org
| Subject: Re: Quo vadis?
|
| On 2018-10-05 01:05 PM, Simon Peyton Jones wrote:
| > I think the difficulty has always been in finding enough people who
| > are
| >
| > * Well-informed and well-qualified
|
I think the difficulty has always been in finding enough people who are
* Well-informed and well-qualified
* Willing to spend the time to standardise language features
GHC does not help the situation: it's a de-facto standard, which reduces the
incentives to spend time in standardisation.
I
ch does not handle top-level bindings. I’m not sure if this is worth
fixing.
Simon
From: José Manuel Calderón Trilla <j...@jmct.cc>
Sent: 15 March 2018 23:17
To: Simon Peyton Jones <simo...@microsoft.com>; haskell-prime@haskell.org;
ghc-d...@haskell.org
Subject: Re: [Haskell] The
Friends
Does anyone know who, if anyone, feels responsible for committing updates to
the Haskell 2010 Report?
Who even has commit rights?
There’s Frank’s pull request below, and I have another important typo to fix.
Thanks
Simon
From: Frank Steffahn [mailto:notificati...@github.com]
Sent:
Good summary Herbert. It'd be great to have it as a page on haskell.org,
rather than just in soon-lost email.
Simon
| -Original Message-
| From: Haskell-prime [mailto:haskell-prime-boun...@haskell.org] On Behalf
| Of Herbert Valerio Riedel
| Sent: 08 September 2017 09:43
| To: Anthony
Just to be clear, MonoLocalBinds, as implemented, does not apply to local
bindings that could equally well have been written at top level; that is, they
do not mention any locally-bound variables (except other local bindings that
could themselves be floated).
So you are at liberty to use where
| For example, much as I love GADTs and would be all for them being added
| in some future language report, I do not feel they should be added this
| time around. (Though I emphatically and wholeheartedly support adding
| GADTSyntax.) The primary reason being that while the semantics of the
|
| It was my understanding that Herbert would be the chair when I asked to
| be on the committee, and the fact that this question was already answer
| was a factor in my decision to try to help. Being the committee chair
| is less a position of power, and more a position of responsibility. I
|
| > Are these three technical capabilities *all* that we would need?
| > Perhaps
| > we also need a way to tie the current language (-XHaskell98,
| > -XHaskell2010) to a particular implementation of the Prelude.
| >
| >
| > I don't have a concrete plan here. I'm not even sure one
| Cc: Simon Peyton Jones; Augustsson, Lennart; Henrik Nilsson; haskell-
| pr...@haskell.org List; Haskell Libraries
| Subject: Re: Breaking Changes and Long Term Support Haskell
|
| Hello,
|
| I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
| only for myself). As I recall, one
| For the record, I am also not sure Proposal 3 is a good idea :)
|
| However, I do think we could clarify what the respective
| responsibilities of the core libraries committee and Haskell Prime
| committees are.
My instinct is this:
Haskell Prime: language
Core Libraries Committee:
Friends
I think it's good for us to debate the question of how we should balance
innovation against change; and how we should make those decisions in future.
Geoff's message had some good ideas, especially this bit:
| Proposal 2: After a suitable period of discussion on the libraries list,
I think there are several different conversations going on at once in this
thread. I think it’s worth keeping them separate.
· Haskell Prime. The intention there is to take a set of language
features that are already in wide use in GHC (i.e. have demonstrably proved
valuable), work
| I have two proposals, I suppose:
| - make bang patterns operate only on variables and wildcards
| - make bang patterns in let altogether invalid
|
| Looking at this again made me realise that, as well as !_ and !varid
| lexemes, we could also alter the decl production so that we get
|
I'd argue that it's not. Haskell hasn't had a release in years, and I think
it's time to put a little pressure on the community.
The question is: who is the community?
It's fairly clear that the Haskell Prime process itself is languishing. The
last message about the development process that I
type-level
| recursion
|
| Simon Peyton-Jones simonpj@... writes:
|
|
| No I didn't intend to put more in the header, perhaps less.
| I've added more clarification.
|
| Simon
|
| Thanks Simon, I agree with keeping it terse; I agree with your yuk
| rating for `of'. At risk of bikeshedding
Cc: haskell-prime@haskell.org
Subject: Re: TypeFamilies vs. FunctionalDependencies type-level recursion
Hi,
On Tue, May 29, 2012 at 11:03 AM, AntC
anthony_clay...@clear.net.nzmailto:anthony_clay...@clear.net.nz wrote:
Simon Peyton-Jones simonpj@...mailto:simonpj@... writes:
See also http
See also http://hackage.haskell.org/trac/ghc/wiki/NewAxioms
(as yet unimplemented)
Simon
| -Original Message-
| From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-
| boun...@haskell.org] On Behalf Of AntC
| Sent: 24 May 2012 14:00
| To: haskell-prime@haskell.org
| Subject: Re:
Don't forget that with -XOverloadedStrings we already have a IsString class.
(That's not a Haskell Prime extension though.)
class IsString a where
fromString :: String - a
Simon
| -Original Message-
| From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-
|
I'm confused too. I'd welcome clarification from the Haskell Prime folk.
S
-Original Message-
From: Serge D. Mechveliani [mailto:mech...@botik.ru]
Sent: 23 December 2011 17:36
To: Simon Peyton-Jones
Subject: Re: 7.4.1-pre: Show Integral
On Thu, Dec 22, 2011 at 08:14:54PM +, Simon
Oleg
| There seems no reason in principle to disallow
| type instance F where
|F Int = Bool
|F a = [a]
|
|
| I would implement this as follows:
|
| type instance F x = F' (EQ (TYPEOF x) INT) x
| type family F' trep x
| type instance F' TRUE x = Bool
| type instance
| GHC trac ticket on the feature, as you probably saw. After a
| discussion with other people here at
| HacPhi, I've decided that what I'm going to attempt is to add
| type-level Maybes
Hang on! Julien Cretin (from INRIA) is doing an internship here at Cambridge
with Dimitrios and me. The
| One thing you could do to help in this specific case would be to use a
| different M1 tag--e.g., M1 S ... for selectors and M1 NS ... for
| fields without selectors (or K1 NS). I presume you've already
| considered this and/or it's too late to make such a change. (Or to
| move the distinction
| I'd like to summarize the relationship between functional dependencies
| and type functions, and propose a solution that should get rid of
| overlapping instances. The solution does not require messing with
| System-FC. In fact, it can be implemented today (although
| ungainly). A small bit of
| By equality superclasses, do you just mean being able to say a ~ b
| in a class context?
Yes. Or (F a ~ b).
| Unless I'm missing something, that is not sufficient to do a lot of
| things I would like to do, as those things require both
| OverlappingInstances and FunctionalDependencies (as
| class C a b | a - b where
| foo :: a - b
| foo = error Yo dawg.
|
| instance C a b where
|
| The instance 'C a b' blatantly violates functional dependency and
| should not have been accepted. The fact that it was is a known bug in
| GHC. The bug keeps getting mentioned on
There was an interesting thread on haskell-prime [1], about the relationship
between functional dependencies and type families. This message is my attempt
to summarise the conclusions of that thread. I'm copying other interested
parties (eg Oleg, Dimitrios)
[1]
|
http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies
|
| Currently under cons for FunctionalDependencies, it says:
|
| AssociatedTypes seem to be more promising.
|
| I proposed the following fix:
|
| AssociatedTypes seem to be more promising, but
But see
http://www.haskell.org/haskellwiki/Library_submissions/NewDraft
for a proposal for updating the core-libraries process.
Simon
| -Original Message-
| From: haskell-prime-boun...@haskell.org
[mailto:haskell-prime-boun...@haskell.org] On
| Behalf Of Ian Lynagh
| Sent: 25 May 2011
See http://hackage.haskell.org/trac/ghc/ticket/4430 for what we are proposing
for Template Haskell.
S
| -Original Message-
| From: haskell-prime-boun...@haskell.org
[mailto:haskell-prime-boun...@haskell.org] On
| Behalf Of Lennart Augustsson
| Sent: 16 November 2010 19:52
| To: Ben
| we implicitly get
| f :: T - Int
| which punning shadows with
| f :: Int
| whereas I generally avoid shadowing completely.
|
| I agree with Ian.
|
| I tend to agree.
I originally had field puns in GHC, and then took them out when Haskell 98
removed them, after a discussion very like
| Similarly, the greatest finite double value can be written as
| 0x1.fp+1023.
|
| These constants have the form
|
|0x[HH][.H]p[+/-]DDD
|
| If you don't want to wait on an (uncertain) inclusion into the Haskell
| standard, you can implement a small helper function to that
| Of course unary minus should bind tighter than any infix operator.
| I remember suggesting this when the language was designed, but the
| Haskell committee was very set against it (mostly Joe Fasel I think).
|
| I think it's too late to change that now, it could really introduce
| some subtle
| This suggests a natural implementation (and specification) for pseq,
|
| pseq :: a - b - b
| pseq x y = x `seq` lazy y
|
| where lazy :: a - a is a compiler provided function equivalent to 'id'
| except that it is considered lazy in its argument by the strictness
| analyzer.
Exactly so! Here
| . Understanding how to respond to type inference and error messages is
| hard enough without having additional differences in innocent-looking
| code. Do you think my hope is reasonable that not-generalizing could
| lead to better error messages?
I don't think it's obvious one way or the
Personally I hate the fact that
f Z {x=3}
parses as
f (Z {a=3})
because even though (as Iavor says) there is only one function application
involved, it *looks* as if there are two.
Equally personally, I think that the presence or absence of white space is a
powerful signal to
| There are a couple sensible removals here. Do we also want to get rid
| of the useless class contexts on data-declarations? (that look like
| data Ord a = Set a = Set ...)
Yes! Yes! Kill them.
(In GHC's source code these contexts are consistently called stupid_theta.)
Simon
| That's why one should really be allowed to group constructor's in a
| type's definition:
|
|data Colour :: * where
| Red, Green, Blue :: Colour
Indeed. GHC allows this now. (HEAD only; will be in 6.12.)
Simon
___
Haskell-prime mailing
| I would thus like to propose the following formalisation of the
| ExplicitForall extension:
What you suggest would be fine with me. Presumably ExplicitForall would be
implied by RankNTypes and the other extensions?
There is a danger of having too *many* choices.
[This email concerns an infelicity in the FFI spec. I'm directing it primarily
to the Haskell Prime mailing list, but ccing the libraries list so that people
there know about the thread. I suggest that replies go to Haskell Prime only.]
Consider this program (see
|* Clarify the spec to say that a newtype can only be automatically
| unwrapped if the newtype constructor (MkN in this case) is in
| scope
|
| I agree up to here. For user-defined types, not exporting the
| constructor should be a guarantee of abstraction.
|
| It happens that a large
| The more I think about it, I think 'superclass' is just the wrong
| terminology for dealing with class aliases. Superclass implies a strict
| partial order on classes, which just isn't the case for class aliases,
| for instance
|
| class alias Foo a = Foo a = Bar a where ...
Crumbs! I have no
| Crumbs! I have no idea what that means! Did you really mean to repeat
Foo? According to your
| expansion in type signatures
| f :: (Foo a) = ...
| expands to
| f :: (Foo a, Bar a) = ...
| which presumably expands again. I'm totally lost here
|
| Yes I did, because I
| Ok. So I counter-propose that we deal with pattern bindings like this:
|
|The static semantics of a pattern binding are given by the following
|translation. A binding 'p = e' has the same meaning as the set of
|bindings
|
| z = e
| x1 = case z of { p - x1 }
| ...
|
Indeed! I think it'd be good to allow type signatures, including instance
signatures, in export lists
module Foo(
data T (f :: * - *),
instance Functor f = Eq (T f),
g :: T f - T f
)
The first step is to evolve a well-worked-out design. I think that'd be a very
| Fair enough. But the strange syntax
|
| class alias Num a = Eq a = (Additive a, Multiplicative a)
|
| *does* seem so say that the (Eq a) behaves in a superclass way, and
| (Additive a, Multiplicative a) behave in a class-alias way, as it
| were. That seems inconsistent with the design
| The report doesn't actually mention this translation although it is
| widely used to implement pattern bindings, and in some compilers (not
| GHC) the translation is done before type checking.
|
| What's interesting to me is that perhaps this gives us a way to
| understand what the static
John
OK here's a question about class alisas. You propose:
class Foo a where
foo :: a - [a]
foo x = []
class Bar a where
bar :: a - a
bar x = [x]
class alias FooBar a = (Foo a, Bar a) where
foobar :: a - a
foobar x = x
foo x =
| Iavor:
| the change is valid. I do believe that you can probably work around
| the problem in many situations but the question in my mind is why
| should we have to work around stuff when we have a system that already
| works? In other words, what problem do MBPs solve?
...
| Neil:
| Haskell
| I tried to see the discussion that led to class aliases being rejected
| as a proposal, but could not find links on the Wiki. In fact, in Trac
| (#101) that proposal is still a 'maybe', but with no updates. Is there
| a competing proposal that got accepted?
|
| [Without a mechanism like class
| Just to clarify, issues of what names can be used for
| type constructors aside, are you proposing dropping
| infix syntax for defining functions, but retaining infix
| syntax for defining types (and type families etc.)?
|
| Or would the last example have to be written
|
| data (+) a b =
| In the end, I think that applicatively used monads are the wrong
| abstraction. For occasional use, liftM2 and `ap` often suffice. If the
| applicative style becomes prevalent, then Applicative Functors are
| likely to be the conceptually better choice. This is especially true
| for
|
Another alternative (which I got from Greg Morrisett) that I'm toying with is
this. It's tiresome to write
do { x - stuff1
; y - sutff2
; f x y }
In ML I'd write simply
f stuff1 stuff2
So Greg's idea (or at least my understanding thereof) is to write it
In the section Changes to the Report of the Wiki page you refer to
http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
I attempted to give the semantics of bang-patterns by saying what changes would
be needed in the Haskell Report. If you think it's incomplete or ambiguous,
problems.
It's certainly a nice challenge.
Simon
|
| Perhaps a good topic for a research paper?
|
| -- Lennart
|
| On Mar 20, 2007, at 12:00 , Simon Peyton-Jones wrote:
|
| | Ganesh and I were discussing today what would happen if one adds Id
| | as a primitive type constructor. How
| Ganesh and I were discussing today what would happen if one adds Id
| as a primitive type constructor. How much did you have to change the
| type checker? Presumably if you need to unify 'm a' with 'a' you now
| have to set m=Id. Do you know if you can run into higher order
| unification
| This reminds me of something I discovered about using strict fields in
| AVL trees (with ghc). Using strict fields results in slower code than
| doing the `seq` desugaring by hand.
That is bad. Can you send a test case that demonstrates this behaviour?
| If I have..
|
| data AVL e = E
|
| | * Pattern matching on polymorphic fields. This does not appear to be
| | too controversial, although Atze had some reservations about this
| | design choice.
...
| So far, most replys seemed to agree that this is not a big
| restriction. Could you give more details on how you think that
| I don't think that the rank-N system is any more expressive then the
| rank-2 one. The reason is that by placing a polymorphic value in a
| datatype we can decrese its rank. In this way we can reduce a program
Hmm. To be consistent, then, you'd have to argue for rank-2 data constructors
Iavor
Does your proposal cover only higher-rank types for *data constructors*? I
don't think there is any problem with extending it to arbitrary functions, as
our paper Practical type inference for higher rank types shows. But the web
page
| judgements (rather than boxes), no impredicativity, etc? As I recall the
| treatment of application expressions there (infer type of the function,
| then check the argument) was considered a bit restrictive. (It forbids
| runST $ foo, for example.)
That requires impredicativity, and that's
| I can also imagine predicates that do not mention locally-quantified
| variables - the assumption must be that they mention variables bound on
| the LHS of the datatype decl instead? e.g. the Show predicate here:
|
| data Foo a b = Foo a b
| | Bar (forall c . (Show b,
| In my opinion, views are going to make more Haskell more complicated, and
| from what I have seen so far, for little gain.
|
| We need some kind of pattern extension *now* for bytestring
| matching/views and bit parsing, though. Stuff that's used in large, real
| world Haskell programs :)
| First, I'm not clear what Simon meant by first class abstractions
| in this comment
|
| Several proposals suggest first class abstractions rather that
| first-class patterns. Here are the ones I know of ...
Sorry to have been un-clear. By a first class abstraction I mean a value of
type
| is that clearer?
yes, thanks. I'm not quite sure whether it all means you think view patterns
are good; or that they would be good with a tweak; or that something else would
be better.
Do feel free to edit the wiki to articulate any design alternatives that you
think deserve consideration.
There's been lots of interesting feedback about the views proposal -- thank you.
Many of the suggestions amount to plausible design alternatives. If I do all
the editing, I'll just become a bottleneck, and I'm more than usually
snowed-under at the moment. So I've moved the Wiki page to the
| 1 I am a bit concerned about the use of non-linear patterns in your examples.
| There are good arguments for non-linear patterns, and Haskellers have
made good
| arguments against non-linear patterns. But you seem to suggest allowing
non-linear
| patterns in some cases (related to
[Redirecting to haskell-prime]
| In the related work, the Active Patterns proposal by Palao et at is missing:
|
| http://portal.acm.org/citation.cfm?id=232641coll=portaldl=ACM
|
| I thought this work should be included in the list because, I believe,
| they were the first to point out that
In my experience I've seen more requests for overloaded *Boolean* literals than
strings. In a Fran context, for example.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Lennart Augustsson
| Sent: 11 November 2006 03:49
| To: Haskell Prime
|
The thread about stand-alone deriving is long-ish now, so I have summarised
the issues here:
http://haskell.org/haskellwiki/GHC/StandAloneDeriving
Perhaps those who are interested can add their thoughts? Bjorn is busy at the
moment, but I think he'll get back to the implementation in a
Thanks for doing this.
Is this the syntax we settled on? I remember we discussed it at some length
S
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Bjorn Bringert
| Sent: 05 October 2006 09:05
| To: haskell-prime@haskell.org
| Subject:
| What is not so nice is that you take a new keyword ('for'), which is
| quite likely to have been used as a variable name in existing code.
(Or
| does it work out to use one of the 'special' names here?)
The latter is what Bjorn has done. That is, 'for' is only special in
this one context.
them
doesn't have impact on their design.
The other alternative I can see is to delay the whole process until we
know more (a year or two), but I can see that is unattractive.
Simon
| -Original Message-
| From: Simon Peyton-Jones
| Sent: 04 May 2006 14:36
| To: [EMAIL PROTECTED]
| Cc
| Superclass implication is reversed when performing type inference.
| In the same way that instance reduction is reserved.
|
| Here's the example again.
|
| class C a
| class F a where
|type T a
| instance F [a] where
|type T [a] = [[[a]]]
| class C (T a) = D a
| ^
|
Good summary. I have made a few edits mainly to clarify what (I think)
is being said.
Under cooperative or preemptive concurrency I'd like someone two write
down as precisely as possible what it means to say the spec requires
cooperative concurrency or the spec requires preemptive concurrency.
| there are interesting problems in FDs, but it seems that the
confluence
| problems were merely problems of the old translation, not anything
| inherent in FDs! I really had hoped we had put that phantom to rest.
Claus
You're doing a lot of work here, which is great. Why not write a paper?
| Any function that is not defineable in (pure) Haskell should be viewed
| with utmost suspicion. The seq function is one of these. At least
| seq has simple denotational semantics, which can't be said for
deepSeq.
|
| I say, put deepSeq in a type class (which is what I've done when I
need
|
| well, there is a difference there in that 'seq' is unimplementable in
| haskell, so the design comitee had freedom to implement it however
they
| wanted.
class Eval a where
seq :: a - b - b
instance Eval (a,b) where
seq (_,_) b = b
| Well, my worry was partly about the suggested version of deepSeq that
| would not diverge on circular structures (since circular structures
| are just one way to implement infinite data structures).
Dynamic idempotence is not the same as detecting circular structures.
Deepseqing a circular
I like this idea. Needs fleshing out though.
| * you can only newtype derive the last argument to a MPTC.
| * you cannot co-derive an instance for multiple newtype renamings.
|
| it seems that both these can be solved when combined with the other
| proposed extension, allowing deriving
Interesting! It'd be great if you've found a simpler more uniform rule.
(Which you seem to be getting rather good at.)Let's see if you can
convince Martin, first, and then articulate the proposed rules. I'll
look fwd to that.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
| let xs' () = 1 : 2 : xs' ()
| let xs2 = xs'
|
| let xs = 1 : 2 : xs
|
| So deepSeq xs2 == _|_, but deepSeq xs == xs
No, no. deepSeq of either should be _|_.
That's easy to achieve, even with the marking idea. Simply do a
depth-first walk, but mark the node *after* traversing all its
| Template Haskell breaks expressions with $,
|
| It's very bad that with TH enabled you cannot write sections of the
form ($ x)
| anymore which are sometimes very handy.
I'd prefer it if TH only sprang into action when you wrote
$x
or
$(f x)
That is, no space after the $. If
My current take, FWIW.
* MPTCs are very useful. They came along very rapidly (well before
H98). I think we must put them in H'
* But MPTCs are hamstrung without FDs or ATs
* FDs and ATs are of the same order of technical difficulty, as Martin
says
* ATs are (I believe) a bit weaker from the
| As mentioned in my email from Tuesday March 21 [1], I'd like to bring
| most threads to a close very soon, and to document your discussions on
| the wiki. The only topics that should remain open are concurrency and
Just before we do I'd like to mention one point that John Hughes and I
| The second header line shows categories, whereas the links in the grey
| boxes are to articles. The idioms category collects together
articles
| that are about idioms.
|
| We could have an idioms or programming techniques article as well,
| of course. It only needs to be written.
Interesting.
If it is sufficiently non-obvious to require this thread, perhaps it'd
be worth adding the relevant guidance can be added to the idioms page
itself?
Incidentally, I looked on the Haskell home page for links to programming
idioms and advice, but came up empty. The obvious place to look was
under
| Incidentally, I looked on the Haskell home page for links to
programming
| idioms and advice, but came up empty. The obvious place to look was
| under Using Haskell, but I didn't find anything. Was I being
stupid?
| Haskell.org is the obvious place to look for advice about
programming in
I often wish that cool tricks like this could be collected on the
Haskell web site. Now that it's a wiki, anyone could do that.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| [EMAIL PROTECTED]
| Sent: 15 March 2006 04:34
| To: [EMAIL
to have a proof that the
relaxation preserves the properties we want. Go right ahead! The paper
provides a good framework for such work, I think.
Simon
| -Original Message-
| From: Claus Reinke [mailto:[EMAIL PROTECTED]
| Sent: 28 February 2006 19:54
| To: Simon Peyton-Jones; haskell-prime
Overlapping instances are undoubtedly useful, but they raise lots of
interesting questions. Such as
- A program that type checks can have its meaning changed by adding an
instance declaration
- Similarly adding import M() can change the meaning of a program (by
changing which instances are
These days, hs-boot files are pretty close to source files, with masses
of stuff omitted.
However, you must process the import declarations of the hs-boot file to
figure out the name spaces involved. In the original source file, you
can't process the import declarations because those modules
] On Behalf Of
| Ashley Yakeley
| Sent: 21 February 2006 20:13
| To: haskell-prime@haskell.org
| Subject: Re: the MPTC Dilemma (please solve)
|
| Simon Peyton-Jones wrote:
|
| Of course -fallow-undecidable-instances still lifts all
restrictions,
| and then all bets are off.
|
| Is the behaviour
| Perhaps this e-mail could be read more generally as a
| request to consistencify/update the (Data) libraries
| in general
...
|
| Is this possible for Haskell'? Or is this too much
| of a break? If it's possible, I'm happy to build a
| wiki page for discussion (I noticed that a short page
With help from Martin Sulzmann and Ross Paterson, GHC (HEAD) now
implements a richer form of functional dependencies than Mark Jones's
version, but still decidable etc. The rules for what must appear in the
context of an instance declaration are also relaxed.
The specification is here:
I've updated the Wiki to add your strict proposal, but rather briefly.
If you want to add stuff, send it to me and I'll add it.
Meanwhile:
| And as a consequence, it is no longer possible to transform a pair of
| bindings into a binding of a pair. In Haskell 98,
|
| p1 = e1
| p2 = e2
|
| I think we should do the simplest thing that could possibly work,
| and then see if we really need more. By work, I mean a compatible
| extension of H98 that makes it possible to add type signatures for
| local bindings (which isn't always possible in H98). How about:
|
| * no implicit
| 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 with the help of fundeps.
A key
| 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:
Another reasonable alternative is
data Set a = Eq a = Set (List a)
1 - 100 of 105 matches
Mail list logo
