Re: Status of Haskell'?

2013-02-01 Thread Ian Lynagh
On Fri, Feb 01, 2013 at 05:31:53PM +, Malcolm Wallace wrote:
> The committee has received no nominations.

At least one was sent. Does haskell-2011-commit...@haskell.org accept
mails from non-members?


Thanks
Ian


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2013-02-01 Thread malcolm.wallace
The committee has received no nominations.  I have asked the committee whether they would like to disband.Regards,
MalcolmOn 01 Feb, 2013,at 05:17 PM, Ian Lynagh  wrote: Hi Malcolm,  On Wed, Dec 12, 2012 at 10:40:53AM +, Malcolm Wallace wrote: >  > Please send nominations to haskell-2011-commit...@haskell.org, summarising your interest and experience. The existing committee will (I hope) make some decision on how to proceed, in early January 2013.  Any progress on this?   Thanks Ian 
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2013-02-01 Thread Ian Lynagh

Hi Malcolm,

On Wed, Dec 12, 2012 at 10:40:53AM +, Malcolm Wallace wrote:
> 
> Please send nominations to haskell-2011-commit...@haskell.org, summarising 
> your interest and experience.  The existing committee will (I hope) make some 
> decision on how to proceed, in early January 2013.

Any progress on this?


Thanks
Ian


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2013-01-05 Thread Malcolm Wallace
On 28/12/2012, at 1:01, Ramana Kumar  wrote:

> On Wed, Dec 12, 2012 at 6:40 PM, Malcolm Wallace  
> wrote:
> There is a mailing list for the members of the language committee: 
> haskell-2011-commit...@haskell.org.  
> 
> Hi Malcolm, could you (or someone) help me out with a link to the archives 
> (if any) for this list, and the listinfo page?


http://www.haskell.org/mailman/listinfo/haskell-2011-committee

But of course, those list archives are private.  All substantive discussion is 
supposed to take place on the Haskell-prime list.  The private committee list 
is only for administration, voting, choice of new committee members, etc.

Regards,
Malcolm
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-27 Thread Henk-Jan van Tuyl
On Fri, 28 Dec 2012 02:01:15 +0100, Ramana Kumar   
wrote:


Hi Malcolm, could you (or someone) help me out with a link to the  
archives

(if any) for this list, and the listinfo page?


http://www.haskell.org/pipermail/haskell-prime/
http://www.haskell.org/mailman/listinfo/haskell-prime

Regards,
Henk-Jan van Tuyl


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-27 Thread Ramana Kumar
On Wed, Dec 12, 2012 at 6:40 PM, Malcolm Wallace wrote:

> There is a mailing list for the members of the language committee:
> haskell-2011-commit...@haskell.org.
>

Hi Malcolm, could you (or someone) help me out with a link to the archives
(if any) for this list, and the listinfo page?
Cheers,
Ramana


> So, given that there are a few people who have expressed interest in
> reviving the language formalisation process, perhaps we should hold
> nominations for a new committee, in the spirit of the method outlined on
> the wiki page:
> http://hackage.haskell.org/trac/haskell-prime/wiki/Committee
>
> Please send nominations to haskell-2011-commit...@haskell.org,
> summarising your interest and experience.  The existing committee will (I
> hope) make some decision on how to proceed, in early January 2013.
>
> Regards,
> Malcolm
>
> On 12 Dec 2012, at 02:42, Ramana Kumar wrote:
>
> > Dear Malcolm,
> >
> > What is the current status of Haskell Prime, as far as you know?
> > (Is there a better way to reach the Haskell Prime committee than just
> emailing the chair?)
> > We have a few volunteers here looking to keep Haskell Prime moving
> forward, and Simon suggested following the tracks of earlier pioneers and
> resuming/joining where they left off.
> >
> > Cheers,
> > Ramana
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-12 Thread Malcolm Wallace
I confess that I have not had enough free time in the last two years to have 
been a good chair for the language committee.  (Using Haskell in the real world 
is just too absorbing!)  I think the next chair should probably be an academic, 
who may have more incentive to spend effort on formalisation of the language 
design process than us industrial types.  (At work, if we want a language 
extension, we just go ahead and implement it - job done.)

There is a mailing list for the members of the language committee: 
haskell-2011-commit...@haskell.org.  It has not seen any activity since 3 
messages in October 2011, and prior to that, a thread of 13 messages in 
Nov/December 2010.  Both of those threads were largely about the vanishingly 
small number of proposals to be decided upon, and whether to issue a new Report 
(the answer being no on both occasions).

So, given that there are a few people who have expressed interest in reviving 
the language formalisation process, perhaps we should hold nominations for a 
new committee, in the spirit of the method outlined on the wiki page:  
http://hackage.haskell.org/trac/haskell-prime/wiki/Committee

Please send nominations to haskell-2011-commit...@haskell.org, summarising your 
interest and experience.  The existing committee will (I hope) make some 
decision on how to proceed, in early January 2013.

Regards,
Malcolm

On 12 Dec 2012, at 02:42, Ramana Kumar wrote:

> Dear Malcolm,
> 
> What is the current status of Haskell Prime, as far as you know?
> (Is there a better way to reach the Haskell Prime committee than just 
> emailing the chair?)
> We have a few volunteers here looking to keep Haskell Prime moving forward, 
> and Simon suggested following the tracks of earlier pioneers and 
> resuming/joining where they left off.
> 
> Cheers,
> Ramana


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-11 Thread Ramana Kumar
Dear Malcolm,

What is the current status of Haskell Prime, as far as you know?
(Is there a better way to reach the Haskell Prime committee than just
emailing the chair?)
We have a few volunteers here looking to keep Haskell Prime moving forward,
and Simon suggested following the tracks of earlier pioneers and
resuming/joining where they left off.

Cheers,
Ramana


On Tue, Dec 4, 2012 at 4:00 AM, Simon Peyton-Jones wrote:

> Stefan, John, Ramana all say:
>
> | I, for one, would love to help out!
>
> Great stuff.  I think the first thing to do is to talk to the 2011 Haskell
> Prime committee
> http://hackage.haskell.org/trac/haskell-prime/wiki/Committee, and ask
> what the status is, as far as they know.  Malcolm asked for proposals at
> the start of 2011 but I'm not sure if he actually received any, or what
> happened after that.
>
> There are guidelines for representation on the committee, and a process
> for forming a new committee on that page.  The process part depends a bit
> on the old committee, and I don't know what they feel now that a "gap year"
> has gone by.  But I'm sure they will appreciate your taking a lead in
> re-booting the process.
>
> Don't be put off by the talk of "a committee".  This isn't bureaucracy!
>  To revise a community language standard there needs to be a group that
> leads the process. It needs to be big enough to have a diversity of view,
> but small enough to make progress. And that's our committee.
>
> Simon
>
> | -Original Message-
> | From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-
> | boun...@haskell.org] On Behalf Of Stefan Holdermans
> | Sent: 02 December 2012 10:24
> | To: haskell-prime@haskell.org
> | Subject: Re: Status of Haskell'?
> |
> | Simon wrote:
> |
> | > I'm sure that any solution will involve (as it did in earlier stages)
> | motivated individuals who are willing to take up leadership roles in
> | developing Haskell's language definition.  I'm copying this to the main
> | Haskell list, in the hope of attracting volunteers!
> |
> |
> | Cheers,
> |
> |   Stefan
> | ___
> | Haskell-prime mailing list
> | Haskell-prime@haskell.org
> | http://www.haskell.org/mailman/listinfo/haskell-prime
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


RE: Status of Haskell'?

2012-12-03 Thread Simon Peyton-Jones
Stefan, John, Ramana all say:

| I, for one, would love to help out!

Great stuff.  I think the first thing to do is to talk to the 2011 Haskell 
Prime committee http://hackage.haskell.org/trac/haskell-prime/wiki/Committee, 
and ask what the status is, as far as they know.  Malcolm asked for proposals 
at the start of 2011 but I'm not sure if he actually received any, or what 
happened after that.

There are guidelines for representation on the committee, and a process for 
forming a new committee on that page.  The process part depends a bit on the 
old committee, and I don't know what they feel now that a "gap year" has gone 
by.  But I'm sure they will appreciate your taking a lead in re-booting the 
process.

Don't be put off by the talk of "a committee".  This isn't bureaucracy!  To 
revise a community language standard there needs to be a group that leads the 
process. It needs to be big enough to have a diversity of view, but small 
enough to make progress. And that's our committee.

Simon

| -Original Message-
| From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-
| boun...@haskell.org] On Behalf Of Stefan Holdermans
| Sent: 02 December 2012 10:24
| To: haskell-prime@haskell.org
| Subject: Re: Status of Haskell'?
| 
| Simon wrote:
| 
| > I'm sure that any solution will involve (as it did in earlier stages)
| motivated individuals who are willing to take up leadership roles in
| developing Haskell's language definition.  I'm copying this to the main
| Haskell list, in the hope of attracting volunteers!
| 
| 
| Cheers,
| 
|   Stefan
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-03 Thread Ross Paterson
On Sun, Dec 02, 2012 at 07:56:57PM +, Gábor Lehel wrote:
> Out of curiosity, to what degree does MultiParamTypeClasses have this
> issue? It seems to me like one of the few extensions which is
> straightforward, widely implemented, uncontroversial, and very useful.

There's some discussion of the linkages at

http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClasses

Without FlexibleInstances, each argument in an instance must be a
type constructor applied to type variables, with no repetition of type
variables across the head.  That would rule out instances like these
from the array packages:

instance IArray Array e
instance MArray (STArray s) e (ST s)
instance Storable e => MArray StorableArray e

Even without these, when reducing contexts you encounter situations
where one argument has a type constructor and another is a type variable.
So you have to change the notions of simple context and context reduction
errors (section 4.5.3).  GHC avoids that by deferring context reduction,
but that opens a whole other can of worms.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-02 Thread Dan Doel
As far as I know, MPTCs alone do not have this issue. But functional
dependencies do, as there are at least two ways they can behave. One is the
way they traditionally behave in GHC, and another is the way they would
behave if they were sugar for type families.

I can't think of anything about MPTCs alone that would be a problem, though.


On Sun, Dec 2, 2012 at 2:56 PM, Gábor Lehel  wrote:

> On Sun, Dec 2, 2012 at 7:06 PM, Dan Doel  wrote:
> > This is a significant problem for even some of the more ubiquitous
> > extensions. For instance, there are multiple compilers that implement
> > RankNTypes, but I would not be surprised at all if programs using that
> > extension were not portable across implementations (they're not really
> even
> > portable across GHC versions).
> >
> > The problem is that RankNTypes is not just about the fact that you are
> > allowed to use such types; every compiler must decide on an inference
> > algorithm that incorporates such types while defaulting to
> Hindley-Milner.
> > But, there are several such algorithms, and they have different trade
> offs
> > as far as where annotations must be placed, or even whether certain
> > conceivably well-typed terms are type checkable (for instance, GHC used
> to
> > do some level of impredicative instantiation; forall a. a -> a could be
> > instantiated to (forall a. a) -> (forall a. a); but this no longer
> works).
> >
> > So, even if we have ubiquitous agreement on the fact that RankNTypes are
> > useful, and implementable, we don't have ubiquitous agreement on the
> > algorithms for implementing them, and which set of trade offs to make.
> But
> > any standard would have to nail all that down, or else programs won't be
> > portable.
> >
> > And this is not the only extension for which this kind of thing is an
> issue.
> >
>
> Out of curiosity, to what degree does MultiParamTypeClasses have this
> issue? It seems to me like one of the few extensions which is
> straightforward, widely implemented, uncontroversial, and very useful.
> For some reason it's been held up by the FDs vs TFs debate, but I
> don't see why it has to be. Vanilla MPTCs on the one hand, and MPTCs
> together with either FDs or TFs on the other hand, serve different use
> cases. If you want a plain type-level relation on types, you use
> MPTCs. If you want some types to be determined by others, then you use
> either FDs or TFs. If we standardize support for the former, that's
> useful, even if we continue to procrastinate on the FDs vs TFs
> question. So if the idea is to do yearly incremental updates to the
> standard, MPTCs looks like the biggest low-hanging fruit to me.
> (Assuming they aren't similarly problematic as RankNTypes.)
>
> --
> Your ship was destroyed in a monadic eruption.
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-02 Thread Gábor Lehel
On Sun, Dec 2, 2012 at 7:06 PM, Dan Doel  wrote:
> This is a significant problem for even some of the more ubiquitous
> extensions. For instance, there are multiple compilers that implement
> RankNTypes, but I would not be surprised at all if programs using that
> extension were not portable across implementations (they're not really even
> portable across GHC versions).
>
> The problem is that RankNTypes is not just about the fact that you are
> allowed to use such types; every compiler must decide on an inference
> algorithm that incorporates such types while defaulting to Hindley-Milner.
> But, there are several such algorithms, and they have different trade offs
> as far as where annotations must be placed, or even whether certain
> conceivably well-typed terms are type checkable (for instance, GHC used to
> do some level of impredicative instantiation; forall a. a -> a could be
> instantiated to (forall a. a) -> (forall a. a); but this no longer works).
>
> So, even if we have ubiquitous agreement on the fact that RankNTypes are
> useful, and implementable, we don't have ubiquitous agreement on the
> algorithms for implementing them, and which set of trade offs to make. But
> any standard would have to nail all that down, or else programs won't be
> portable.
>
> And this is not the only extension for which this kind of thing is an issue.
>

Out of curiosity, to what degree does MultiParamTypeClasses have this
issue? It seems to me like one of the few extensions which is
straightforward, widely implemented, uncontroversial, and very useful.
For some reason it's been held up by the FDs vs TFs debate, but I
don't see why it has to be. Vanilla MPTCs on the one hand, and MPTCs
together with either FDs or TFs on the other hand, serve different use
cases. If you want a plain type-level relation on types, you use
MPTCs. If you want some types to be determined by others, then you use
either FDs or TFs. If we standardize support for the former, that's
useful, even if we continue to procrastinate on the FDs vs TFs
question. So if the idea is to do yearly incremental updates to the
standard, MPTCs looks like the biggest low-hanging fruit to me.
(Assuming they aren't similarly problematic as RankNTypes.)

-- 
Your ship was destroyed in a monadic eruption.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-02 Thread Dan Doel
This is a significant problem for even some of the more ubiquitous
extensions. For instance, there are multiple compilers that implement
RankNTypes, but I would not be surprised at all if programs using that
extension were not portable across implementations (they're not really even
portable across GHC versions).

The problem is that RankNTypes is not just about the fact that you are
allowed to use such types; every compiler must decide on an inference
algorithm that incorporates such types while defaulting to Hindley-Milner.
But, there are several such algorithms, and they have different trade offs
as far as where annotations must be placed, or even whether certain
conceivably well-typed terms are type checkable (for instance, GHC used to
do some level of impredicative instantiation; forall a. a -> a could be
instantiated to (forall a. a) -> (forall a. a); but this no longer works).

So, even if we have ubiquitous agreement on the fact that RankNTypes are
useful, and implementable, we don't have ubiquitous agreement on the
algorithms for implementing them, and which set of trade offs to make. But
any standard would have to nail all that down, or else programs won't be
portable.

And this is not the only extension for which this kind of thing is an issue.

-- Dan


On Sun, Dec 2, 2012 at 6:42 AM, Ross Paterson  wrote:

> On Fri, Nov 30, 2012 at 11:05:41PM +, Gábor Lehel wrote:
> > Well, I'm not so sure it's a great idea to just bake "what GHC does at
> > this moment" (for any particular extension) into the standard without
> > really thinking about it. Even then, you have to figure out, in great
> > detail, what GHC does, and write it all down! That's not negligible
> > effort, either.
>
> And that is the core of the problem.  The standard isn't just a list
> of approved features.  It needs to describe them in such detail that a
> programmer can tell, from the Report alone, whether a particular program
> is legal, and if so what it's supposed to do.  We don't have that level
> of description for these extensions, and creating it will be a lot of
> hard work.
>
> Relying on "what GHC does at the moment" has obvious risks for
> programmers, it also puts an unfair responsibility on GHC itself.  How can
> they improve a feature if it's current implementation is the "standard"?
>
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-02 Thread Ross Paterson
On Fri, Nov 30, 2012 at 11:05:41PM +, Gábor Lehel wrote:
> Well, I'm not so sure it's a great idea to just bake "what GHC does at
> this moment" (for any particular extension) into the standard without
> really thinking about it. Even then, you have to figure out, in great
> detail, what GHC does, and write it all down! That's not negligible
> effort, either.

And that is the core of the problem.  The standard isn't just a list
of approved features.  It needs to describe them in such detail that a
programmer can tell, from the Report alone, whether a particular program
is legal, and if so what it's supposed to do.  We don't have that level
of description for these extensions, and creating it will be a lot of
hard work.

Relying on "what GHC does at the moment" has obvious risks for
programmers, it also puts an unfair responsibility on GHC itself.  How can
they improve a feature if it's current implementation is the "standard"?

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-02 Thread Ramana Kumar
Me too, if I can.


On Sun, Dec 2, 2012 at 10:23 AM, Stefan Holdermans  wrote:

> Simon wrote:
>
> > I’m sure that any solution will involve (as it did in earlier stages)
> motivated individuals who are willing to take up leadership roles in
> developing Haskell’s language definition.  I’m copying this to the main
> Haskell list, in the hope of attracting volunteers!
>
> I, for one, would love to help out!
>
> Cheers,
>
>   Stefan
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-02 Thread Stefan Holdermans
Simon wrote:

> I’m sure that any solution will involve (as it did in earlier stages) 
> motivated individuals who are willing to take up leadership roles in 
> developing Haskell’s language definition.  I’m copying this to the main 
> Haskell list, in the hope of attracting volunteers!

I, for one, would love to help out!

Cheers,

  Stefan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-01 Thread Jason Dusek
2012/11/30 Gábor Lehel :
> Well, I'm not so sure it's a great idea to just bake "what GHC
> does at this moment" (for any particular extension) into the
> standard without really thinking about it. Even then, you have
> to figure out, in great detail, what GHC does, and write it
> all down! That's not negligible effort, either. And the
> alternative is to also publicly discuss and hash all of it out
> down to the little tiny gritty stuff. But wanting to write a
> new standard (big effort!) just to get rid of some pragmas and
> make people feel better (small payoff!) feels like a mismatch
> to me.

It is a large payoff, considering the thousands and thousands of
people that it creates a small payoff for: people writing
Haskell, people learning Haskell, people teaching Haskell. A
standard is a lot of effort for a handful of people.

--
Jason Dusek
pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: [Haskell] Status of Haskell'?

2012-12-01 Thread Jason Dusek
2012/12/1 Tijn van der Zant :
> I think that there is more to take into account.
> Haskell is growing as a language that people use to solve scientific and
> business problems. It is starting to become more of a working language,
> which is a very good thing of course. But this also means that Haskell
> should accommodate the people who are only working with it (not developing
> the language) and might not have a clue about the developers of the
> language. I'm somewhere in between where I love to read about the
> developments (this is my first post) and use it to program robots in my lab
> (besides some other languages).
> To accommodate the people who just want to use Haskell, we might have a
> super-pragma (as previously proposed) and for those gaining skill it should
> be possible to subtract pragmas until you have turned them all off and you
> can call yourself a Haskell guru. Mind you, I am not one of those, simply
> because I have to program in 5 languages for my work. For me, all those
> pragmas are not a matter of ugliness, but more an annoyance. For starters it
> is even worse. They ask questions such as: What do I turn on? Did I already
> find a good pragma tutorial? Why do I need to know about pragmas if it is
> already difficult to learn the language? By subtracting the pragmas (or
> turning them off) people can learn what they actually do and improve their
> code and their thinking about the language.
> Quite often I need the get something done, and due to time pressure I do not
> always have the luxury to make the code beautiful. And since it is Haskell
> (if it compiles it probably does what you want) I do not always care. For
> many users, pragmas are a Haskell concept that they can live without in the
> first part of their Haskell programming career (and they just turn a load of
> them on without even thinking about it what they do, but hey, the code works
> now!...)
> I think that we should accommodate the 'working programmers' and make their
> life a little bit easier, so that it becomes easier to start programming in
> Haskell and the language can be put to use by more people.
> This does not exclude having a 'pragma prime' that includes proposals for
> Haskell' of course. But it would help people starting with Haskell a lot
> imho.

Thank you for highlighting the many ways in which pragmas are
a problem from a practical point of view.

--
Jason Dusek
pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-12-01 Thread Roman Cheplyaka
* Simon Peyton-Jones  [2012-11-30 16:36:01+]
> Why not?  I don't think it's laziness or selfishness; just look at how
> helpful people are on the mailing list.  Rather, I am guessing that
> it's a subconscious assessment of cost/benefit.  The cost is certainly
> significant, and (unlike a quick email response on Haskell Cafe) takes
> place over months.
> 
> The benefit, for an individual, is harder to articulate.   GHC defines
> a de-facto standard, simply by existing, and for many practical
> purposes that is good enough.  However, GHC is (quite consciously)
> exploring stuff that may or may not ultimately turn out to be a good
> idea: it's a laboratory, not an every-detail-thought-out product.
> [Though of course we try hard to be good enough for production use.]
> So there is real merit in having a group, not too closely coupled to
> GHC, that picks off the best ideas and embodies them in a language
> standard.   But if for any one individual, GHC is "good enough", then
> the benefits of a language standard may seem distant and diffuse.
> 
> I don't have a solution to this particular conundrum.  As many of you
> will remember, the Haskell Prime
> process
> was itself developed in response to a sense that making a "big
> iteration" of the language was so large a task that no one felt able
> to even begin it.  Hence the deliberately more incremental nature of
> Haskell Prime; but even this lighter-weight process is rather stuck.
> 
> I'm sure that any solution will involve (as it did in earlier stages)
> motivated individuals who are willing to take up leadership roles in
> developing Haskell's language definition.  I'm copying this to the
> main Haskell list, in the hope of attracting volunteers!

Thanks — I think this is a good analysis of the situation.

One thing I'd like to add is that working on the standard not only
takes more effort compared to responding on the mailing list, but it
also requires a much higher level of competence.

Roman

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: [Haskell] Status of Haskell'?

2012-12-01 Thread Roman Cheplyaka
* Tijn van der Zant  [2012-12-01 10:00:31+0100]
> Why do I need to know about pragmas if it is already difficult to
> learn the language?

Exactly. In an ideal world, where the language standard corresponds to
what people perceive as being standard, beginners shouldn't know or care
about pragmas, which by definition enable non-portable and experimental
features.

And the last thing a beginner should do is to enable ALL of those
obscure features.

> (and they just turn a load of them on without even thinking about it
> what they do, but hey, the code works now!...)

That is an unfortunate situation in which we are now, and which could be
improved by releasing a new standard incorporating the most tested and
widely-used features.

Roman

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: [Haskell] Status of Haskell'?

2012-12-01 Thread Roman Cheplyaka
* Henning Thielemann  [2012-12-01 00:37:12+0100]
> We should have multiple implementations before standardization.

Alternative implementations already exist for lots of extenstions, see
http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions

Roman

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-30 Thread Gábor Lehel
On Fri, Nov 30, 2012 at 11:06 PM, Nate Soares  wrote:
>
>> This standardization process amounts to "endorsement of existing
>> features" which seems like not a bad process at all. It makes
>> the standard descriptive rather than predictive.
>
>
> +1. I agree generally with Gabor's points -- GHC is in the drivers seat. But
> at some point we should take a look at all the things GHC has made that did
> pay off and that are good and make them official.
>
> I'd very much like to see that endorsement happen soon, even if it's not
> aggressive.

Well, I'm not so sure it's a great idea to just bake "what GHC does at
this moment" (for any particular extension) into the standard without
really thinking about it. Even then, you have to figure out, in great
detail, what GHC does, and write it all down! That's not negligible
effort, either. And the alternative is to also publicly discuss and
hash all of it out down to the little tiny gritty stuff. But wanting
to write a new standard (big effort!) just to get rid of some pragmas
and make people feel better (small payoff!) feels like a mismatch to
me.

Maybe as some kind of useful in-between point, the GHC folks could
figure out which extensions they like enough that they would, modulo
all the details getting figured out and specified, be in favor of them
going into a new standard, and fold all of them into a new LANGUAGE
definition? So then you would write {-# LANGUAGE HaskellNext #-}, or
HaskellGHC, or something like that, to enable all of them in one go.
That wouldn't require specifying things down to the tiniest details
(which is what a standard requires), but only at the granularity of
particular extensions, which is what people seem to be looking for.
Maybe instead of the GHC people deciding it, there could be some kind
of community process (such as a vote). (And yeah, this sounds eerily
similar to -fglasgow-exts, which is what we got rid of in favor of
LANGUAGE pragmas, but maybe the fact that -fglasgow-exts turned mostly
all extensions on indiscriminately, whereas this would be a curated
subset, is a significant enough difference to turn it from a bad idea
into a good one.)


-- 
Your ship was destroyed in a monadic eruption.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: [Haskell] Status of Haskell'?

2012-11-30 Thread Johan Tibell
On Fri, Nov 30, 2012 at 1:42 PM, Jason Dusek  wrote:
> It would be nice for there to be a new standard so that many
> features in GHC -- such as overloaded strings, rank n types,
> MPTCs, &c. -- were enabled by default without any pragmas.

I think this is one of these nice gains for day-to-day Haskell
programming. Less typing and fewer things to explain to beginners
("You see, this might seem like an experimental feature I'm asking you
to use, but it really isn't.")

-- Johan

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-30 Thread Nate Soares
> This standardization process amounts to "endorsement of existing
> features" which seems like not a bad process at all. It makes
> the standard descriptive rather than predictive.
>

+1. I agree generally with Gabor's points -- GHC is in the drivers seat.
But at some point we should take a look at all the things GHC has made that
did pay off and that are good and make them official.

I'd very much like to see that endorsement happen soon, even if it's
not aggressive.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-30 Thread Jason Dusek
2012/11/30 Gábor Lehel :
> Executive summary: We don't need a new standard right now. If
> people don't think it's worth their while to work on it,
> they're probably right. New, competing implementations might
> be valuable. If we have them, there will be demand for a
> standard, making decisions about it will be easier, and it
> will probably be better.

It would be nice for there to be a new standard so that many
features in GHC -- such as overloaded strings, rank n types,
MPTCs, &c. -- were enabled by default without any pragmas.

This standardization process amounts to "endorsement of existing
features" which seems like not a bad process at all. It makes
the standard descriptive rather than predictive.

--
Jason Dusek
pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-30 Thread Gábor Lehel
, we would have a rich body of experience
to draw on from the different implementations. Right now, it looks
like "we know what GHC does" and then bikeshedding about "but maybe
another way would be better?", without experience to inform it.
Decisions are harder to make that way, and we can be less certain that
they're right.

Executive summary: We don't need a new standard right now. If people
don't think it's worth their while to work on it, they're probably
right. New, competing implementations might be valuable. If we have
them, there will be demand for a standard, making decisions about it
will be easier, and it will probably be better.

That's my two forints.

- Gábor

* I don't actually like ponies, but I suppose everyone else does.


>
>
>
> From: haskell-prime-boun...@haskell.org
> [mailto:haskell-prime-boun...@haskell.org] On Behalf Of Nate Soares
> Sent: 27 November 2012 22:44
> To: Ben Millwood
> Cc: haskell-prime@haskell.org Prime
> Subject: Re: Status of Haskell'?
>
>
>
>> it might be wise to see what GHC decides to do on that front, first,
>
>
>
> 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.
>
>
>
> On Tue, Nov 27, 2012 at 2:15 PM, Ben Millwood 
> wrote:
>
> On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh  wrote:
>> [...] adding DeriveDataTypeable
>> hopefully wouldn't be too controversial [...]
>
> This is a little tricky since the Data class itself makes (essential,
> I think) use of Rank2Types. Typeable ought to be fine, but it might be
> wise to see what GHC decides to do on that front, first, e.g. whether
> it's going to autoderive all instances or forbid user instances or
> anything else similarly bold.
>
>
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
>
>
>
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>



-- 
Your ship was destroyed in a monadic eruption.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


RE: Status of Haskell'?

2012-11-30 Thread Simon Peyton-Jones
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 can find is this one from 
Malcolm 
Wallace<http://www.haskell.org/pipermail/haskell-prime/2011-January/003335.html>,
 in January 2011.

But please don't blame Malcolm or the 
committee<http://hackage.haskell.org/trac/haskell-prime/wiki/Committee>.  
Developing new, well-specified changes to Haskell will only happen if there is 
a vigorous eco-system of folk who are prepared to devote the love and time to 
do it.  There are plenty of people (myself among them) who would be delighted 
if there was a series of well-specified updates to the Haskell standard; but it 
is harder to assemble a group that is willing to move that process forward.

Why not?  I don't think it's laziness or selfishness; just look at how helpful 
people are on the mailing list.  Rather, I am guessing that it's a subconscious 
assessment of cost/benefit.  The cost is certainly significant, and (unlike a 
quick email response on Haskell Cafe) takes place over months.

The benefit, for an individual, is harder to articulate.   GHC defines a 
de-facto standard, simply by existing, and for many practical purposes that is 
good enough.  However, GHC is (quite consciously) exploring stuff that may or 
may not ultimately turn out to be a good idea: it's a laboratory, not an 
every-detail-thought-out product.  [Though of course we try hard to be good 
enough for production use.]  So there is real merit in having a group, not too 
closely coupled to GHC, that picks off the best ideas and embodies them in a 
language standard.   But if for any one individual, GHC is "good enough", then 
the benefits of a language standard may seem distant and diffuse.

I don't have a solution to this particular conundrum.  As many of you will 
remember, the Haskell Prime 
process<http://hackage.haskell.org/trac/haskell-prime/wiki/Process> was itself 
developed in response to a sense that making a "big iteration" of the language 
was so large a task that no one felt able to even begin it.  Hence the 
deliberately more incremental nature of Haskell Prime; but even this 
lighter-weight process is rather stuck.

I'm sure that any solution will involve (as it did in earlier stages) motivated 
individuals who are willing to take up leadership roles in developing Haskell's 
language definition.  I'm copying this to the main Haskell list, in the hope of 
attracting volunteers!

Simon

From: haskell-prime-boun...@haskell.org 
[mailto:haskell-prime-boun...@haskell.org] On Behalf Of Nate Soares
Sent: 27 November 2012 22:44
To: Ben Millwood
Cc: haskell-prime@haskell.org Prime
Subject: Re: Status of Haskell'?

> it might be wise to see what GHC decides to do on that front, first,

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.

On Tue, Nov 27, 2012 at 2:15 PM, Ben Millwood 
mailto:hask...@benmachine.co.uk>> wrote:
On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh 
mailto:ig...@earth.li>> wrote:
> [...] adding DeriveDataTypeable
> hopefully wouldn't be too controversial [...]

This is a little tricky since the Data class itself makes (essential,
I think) use of Rank2Types. Typeable ought to be fine, but it might be
wise to see what GHC decides to do on that front, first, e.g. whether
it's going to autoderive all instances or forbid user instances or
anything else similarly bold.

___
Haskell-prime mailing list
Haskell-prime@haskell.org<mailto:Haskell-prime@haskell.org>
http://www.haskell.org/mailman/listinfo/haskell-prime

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-27 Thread Nate Soares
> it might be wise to see what GHC decides to do on that front, first,

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.


On Tue, Nov 27, 2012 at 2:15 PM, Ben Millwood wrote:

> On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh  wrote:
> > [...] adding DeriveDataTypeable
> > hopefully wouldn't be too controversial [...]
>
> This is a little tricky since the Data class itself makes (essential,
> I think) use of Rank2Types. Typeable ought to be fine, but it might be
> wise to see what GHC decides to do on that front, first, e.g. whether
> it's going to autoderive all instances or forbid user instances or
> anything else similarly bold.
>
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-27 Thread Ben Millwood
On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh  wrote:
> [...] adding DeriveDataTypeable
> hopefully wouldn't be too controversial [...]

This is a little tricky since the Data class itself makes (essential,
I think) use of Rank2Types. Typeable ought to be fine, but it might be
wise to see what GHC decides to do on that front, first, e.g. whether
it's going to autoderive all instances or forbid user instances or
anything else similarly bold.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-27 Thread Ian Lynagh
On Tue, Nov 27, 2012 at 11:44:51AM -0500, Brandon Allbery wrote:
> On Tue, Nov 27, 2012 at 10:50 AM, Nate Soares  wrote:
> 
> > I second this question. At what point do we cut Haskell' with what we
> > have, release it, and push the big undecideds back to Haskell"?
> 
> Maybe the question is whether we have anything.  We already skipped 2011
> because there wasn't anything worth the effort of a new standard.

FWIW, I stopped working on writing things up as proposals after (TTBOMK)
http://www.haskell.org/pipermail/haskell-prime/2011-February/003362.html
didn't happen.

The big things (GADTs, FD vs AT, etc) are probably still some way off,
but there are plenty of incremental changes that we could make now to
improve the language. For example, adding negative literals should be
simple and would be nice to have, and adding DeriveDataTypeable
hopefully wouldn't be too controversial and would help us reach a point
where people don't feel the need to use CPP and/or hand-write instances.


Thanks
Ian


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-27 Thread Roman Cheplyaka
* Brandon Allbery  [2012-11-27 12:11:43-0500]
> On Tue, Nov 27, 2012 at 12:07 PM, Roman Cheplyaka  wrote:
> 
> > > Maybe the question is whether we have anything.  We already skipped 2011
> > > because there wasn't anything worth the effort of a new standard.
> >
> > How about MultiParamTypeClasses, RankNTypes, ExistentialQuantification,
> >
> 
> Do we have a definitive go/no-go on the FDs vs. TFs question yet?  I
> thought MPTC was not considered usable without one of those, and neither is
> yet considered standard (with some good reason in the case of FDs).

I see MPTCs and TFs as independent, in the sense that each one is usable
without the other. MPTCs allow the implementation to depend on multiple
types, while TFs allow the implementation *and* some other types to
depend on one type. Of course, in combination they are even more
powerful, allowing to have several "basis" types and several "dependent"
types.

FDs are a bit different because they are not usable without MPTC.

Thus, FDs aside, MPTC usefulness should not depend on whether we accept
TFs.

(FWIW, I agree with Edward that both FDs and TFs are very useful in
practice.)

Roman

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-27 Thread Edward Kmett
I think it has proven out pretty well in practice that probably want both
in the surface language. I know minimalists on the TF side of the debate
have tried to make the case that you don't even need FDs in the surface
syntax, but there are lots of places where it having a class with multiple
directional constraints makes the code much, much more sane.

I would be loathe to sacrifice either of them.

-Edward

On Tue, Nov 27, 2012 at 12:11 PM, Brandon Allbery wrote:

> uestion yet?  I thought MPTC was not considered usable without one of
> those, and neither is yet considered standard (with some good reason in the
> case of FDs).
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-27 Thread Brandon Allbery
On Tue, Nov 27, 2012 at 12:07 PM, Roman Cheplyaka  wrote:

> > Maybe the question is whether we have anything.  We already skipped 2011
> > because there wasn't anything worth the effort of a new standard.
>
> How about MultiParamTypeClasses, RankNTypes, ExistentialQuantification,
>

Do we have a definitive go/no-go on the FDs vs. TFs question yet?  I
thought MPTC was not considered usable without one of those, and neither is
yet considered standard (with some good reason in the case of FDs).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix/linux, openafs, kerberos, infrastructure  http://sinenomine.net
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-27 Thread Roman Cheplyaka
* Brandon Allbery  [2012-11-27 11:44:51-0500]
> On Tue, Nov 27, 2012 at 10:50 AM, Nate Soares  wrote:
> 
> > I second this question. At what point do we cut Haskell' with what we
> > have, release it, and push the big undecideds back to Haskell"?
> 
> 
> Maybe the question is whether we have anything.  We already skipped 2011
> because there wasn't anything worth the effort of a new standard.

How about MultiParamTypeClasses, RankNTypes, ExistentialQuantification,
GADTs? They've been around for quite some time and turned out very
useful in practice.

Roman

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-27 Thread Brandon Allbery
On Tue, Nov 27, 2012 at 10:50 AM, Nate Soares  wrote:

> I second this question. At what point do we cut Haskell' with what we
> have, release it, and push the big undecideds back to Haskell"?


Maybe the question is whether we have anything.  We already skipped 2011
because there wasn't anything worth the effort of a new standard.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix/linux, openafs, kerberos, infrastructure  http://sinenomine.net
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell'?

2012-11-27 Thread Nate Soares
I second this question. At what point do we cut Haskell' with what we have,
release it, and push the big undecideds back to Haskell"?


On Mon, Nov 26, 2012 at 8:09 AM, Roman Cheplyaka  wrote:

> Hi,
>
> Can someone comment on the status of Haskell'?
>
> As I understood from [1], new language releases were supposed to be made
> annually, and there hasn't been a release for 3 years.
>
> [1]: http://hackage.haskell.org/trac/haskell-prime/wiki/Process
>
> Roman
>
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Status of Haskell'?

2012-11-26 Thread Roman Cheplyaka
Hi,

Can someone comment on the status of Haskell'?

As I understood from [1], new language releases were supposed to be made
annually, and there hasn't been a release for 3 years.

[1]: http://hackage.haskell.org/trac/haskell-prime/wiki/Process

Roman

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell Prime Language definition

2007-10-18 Thread apfelmus

Iavor Diatchki wrote:

http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies#Lossofconfluence


There is nothing about the system being unsound there.  Furthermore, I
am unclear about the problem described by the link...  The two sets of
predicates are logically equivalent (have the same set of ground
instances), here is a full derivation:

(B a b, C [a] c d)
using the instance
(B a b, C [a] c d, C [a] b Bool)
using the FD rule
(B a b, C [a] c d, C [a] b Bool, b = c)
using b = c
(B a b, C [a] c d, C [a] b Bool, b = c, C [a] b d)
omitting unnecessary predicates and rearranging:
(b = c, B a b, C [a] b d)

The derivation in the other direction is much simpler:
(b = c, B a b, C [a] b d)
using b = c
(b = c, B a b, C [a] b d, C [a] c d)
omitting unnecessary predicates
(B a b, C [a] c d)


You're right, I think I'm mixing up soundness with completeness and 
termination. My thought was that not explicitly mentioning the b=c 
constraint could lead to the type inference silently dropping this fact 
and letting an inconsistent set of instance declarations "go through" 
without noticing. But that would only be important in a setting where 
inconsistent instances are not reported early via the consistency 
condition but late when actually constructing terms. The consistency 
condition should be enough for soundness (no inconsistent axioms 
accepted), but I didn't dwell enough into FD to know such things for sure.


Regards,
apfelmus

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell Prime Language definition

2007-10-16 Thread Iavor Diatchki
Hello,

On 10/16/07, apfelmus <[EMAIL PROTECTED]> wrote:
> Iavor Diatchki wrote:
> > apfelmus wrote:
> >> fundeps are too tricky to get powerful and sound at the same time.
> >
> > I am not aware of any soundness problems related to functional
> > dependencies---could you give an example?
>
> http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies#Lossofconfluence
>
> But I should have said "sound, complete and decidable" instead :)

There is nothing about the system being unsound there.  Furthermore, I
am unclear about the problem described by the link...  The two sets of
predicates are logically equivalent (have the same set of ground
instances), here is a full derivation:

(B a b, C [a] c d)
using the instance
(B a b, C [a] c d, C [a] b Bool)
using the FD rule
(B a b, C [a] c d, C [a] b Bool, b = c)
using b = c
(B a b, C [a] c d, C [a] b Bool, b = c, C [a] b d)
omitting unnecessary predicates and rearranging:
(b = c, B a b, C [a] b d)

The derivation in the other direction is much simpler:
(b = c, B a b, C [a] b d)
using b = c
(b = c, B a b, C [a] b d, C [a] c d)
omitting unnecessary predicates
(B a b, C [a] c d)

-- 
Iavor
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell Prime Language definition

2007-10-16 Thread Philippa Cowderoy
On Tue, 16 Oct 2007, apfelmus wrote:

> Robert Will wrote:
> > Could someone please summarize the current status and planned time
> > line for Haskell'?
> 
> John Launchbury wrote:
> > Up to now, the Haskell' effort has been mostly about exploring the
> > possibilities, to find out what could be in Haskell', and to scope out
> > what it might mean. We've now reached the stage where we want to do the
> > opposite, namely trying to pin down what we definitely want to have in
> > the standard, and what it should look like in detail.
> 
> There's still a major technical obstacle, namely  functional dependencies
> vs  associated type synonyms .

The right thing is probably to admit that it's going to take a few years 
to resolve adequately, get a standard now and get a new standard or an 
addendum when those few years are up. This has the problem that it leaves 
us with crippled interfaces for standard libraries, but we already have 
that problem!

-- 
[EMAIL PROTECTED]

Sometimes you gotta fight fire with fire. Most
of the time you just get burnt worse though.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell Prime Language definition

2007-10-16 Thread apfelmus

Iavor Diatchki wrote:

apfelmus wrote:

fundeps are too tricky to get powerful and sound at the same time.


I am not aware of any soundness problems related to functional
dependencies---could you give an example?


http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies#Lossofconfluence

But I should have said "sound, complete and decidable" instead :)

Regards,
apfelmus

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell Prime Language definition

2007-10-16 Thread Iavor Diatchki
Hello,

On 10/16/07, apfelmus <[EMAIL PROTECTED]> wrote:
> Robert Will wrote:
> > Could someone please summarize the current status and planned time
> > line for Haskell'?
>
> John Launchbury wrote:
> > Up to now, the Haskell' effort has been mostly about exploring the
> > possibilities, to find out what could be in Haskell', and to scope out
> > what it might mean. We've now reached the stage where we want to do the
> > opposite, namely trying to pin down what we definitely want to have in
> > the standard, and what it should look like in detail.
>
> There's still a major technical obstacle, namely  functional
> dependencies  vs  associated type synonyms . Some functionality for
> programming in the type system is needed for Haskell' but fundeps are
> too tricky to get powerful and sound at the same time. The problem with
> their promising alternative of associated type synonyms is that they're
> very young with their first official release being the upcoming GHC 6.8
> . So, they have to stand some test of time before Haskell' can pick one
> of the two (probably the latter).

I am not aware of any soundness problems related to functional
dependencies---could you give an example?

-Iavor
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell Prime Language definition

2007-10-16 Thread apfelmus

Robert Will wrote:

Could someone please summarize the current status and planned time
line for Haskell'?


John Launchbury wrote:
Up to now, the Haskell' effort has been mostly about exploring the 
possibilities, to find out what could be in Haskell', and to scope out 
what it might mean. We've now reached the stage where we want to do the 
opposite, namely trying to pin down what we definitely want to have in 
the standard, and what it should look like in detail.


There's still a major technical obstacle, namely  functional 
dependencies  vs  associated type synonyms . Some functionality for 
programming in the type system is needed for Haskell' but fundeps are 
too tricky to get powerful and sound at the same time. The problem with 
their promising alternative of associated type synonyms is that they're 
very young with their first official release being the upcoming GHC 6.8 
. So, they have to stand some test of time before Haskell' can pick one 
of the two (probably the latter).


Regards,
apfelmus

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: Status of Haskell Prime Language definition

2007-10-15 Thread John Launchbury

Hi Robert,

At the recent Haskell workshop, I stood up and gave the following  
summary (approximately):


Up to now, the Haskell' effort has been mostly about exploring the  
possibilities, to find out what could be in Haskell', and to scope  
out what it might mean. We've now reached the stage where we want to  
do the opposite, namely trying to pin down what we definitely want to  
have in the standard, and what it should look like in detail. I've  
set aside a chunk of my own time this fall to help coordinate the  
activity, write text etc. I'm hoping that things should be pretty  
clear by early next year.


I have spoken with CUP and JFP about publishing the standard as a  
special issue of JFP and as a book, and they are interested. The  
strawman timeline for that is early next summer.


Hope this helps,
John


On Oct 11, 2007, at 9:34 PM, Robert Will wrote:


Hi all,

When I first discovered Haskell' I was really excited to hear that
many of the individual extensions that are already used by many people
are going to be put together to one coherent next release.

I have read the archive of the Haskell Prime Mailing list for all of
2007 as well as a lot of pages on Haskell.org and in the Haskell Prime
Wiki, yet the most recent status report that I found is the one in the
wiki from September 2006.
(http://hackage.haskell.org/trac/haskell-prime/wiki/Status')

Could someone please summarize the current status and planned time
line for Haskell'?

thanks a lot,
Robert

--
Skype: robert.will
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime



John Launchbury   | galois |   (503)626-6616 x104


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Fwd: Status of Haskell Prime Language definition

2007-10-11 Thread Robert Will
Hi all,

When I first discovered Haskell' I was really excited to hear that
many of the individual extensions that are already used by many people
are going to be put together to one coherent next release.

I have read the archive of the Haskell Prime Mailing list for all of
2007 as well as a lot of pages on Haskell.org and in the Haskell Prime
Wiki, yet the most recent status report that I found is the one in the
wiki from September 2006.
(http://hackage.haskell.org/trac/haskell-prime/wiki/Status')

Could someone please summarize the current status and planned time
line for Haskell'?

thanks a lot,
Robert

--
Skype: robert.will
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime