On May 4, 2010, at 05:09 , Duncan Coutts wrote:
On Fri, 2010-04-30 at 10:42 +0100, Simon Marlow wrote:
Bear in mind these goals: we want to
a. support writing code that is Haskell 2010 only: it only uses
Haskell 2010 language features and modules.
b. not break existing code as far as
On Fri, 2010-04-30 at 10:42 +0100, Simon Marlow wrote:
> Hi Folks,
>
> I'm editing the Haskell 2010 report right now, and trying to decide what
> to do about the libraries. During the Haskell 2010 process the
> committee agreed that the libraries in the report should be updated,
> using the cu
On Fri, 2010-04-30 at 10:42 +0100, Simon Marlow wrote:
> Here are some options:
>
>3. allow packages to shadow each other, so haskell2010 shadows
> base. This is a tantalising possibility, but I don't have
> any idea what it would look like, e.g. should the client or
> the
On 01/05/10 20:17, Ian Lynagh wrote:
On Sat, May 01, 2010 at 08:05:58PM +0100, Simon Marlow wrote:
On 01/05/10 17:16, Ian Lynagh wrote:
So it seems this is closer to option (2) in my message, because
portablebase and haskell2010 overlap, and are therefore mutually
exclusive, whereas in (4) has
On May 1, 2010, at 15:05 , Simon Marlow wrote:
On 01/05/10 17:16, Ian Lynagh wrote:
Oh, I thought the plan was for library standardisation in the
report to
be reduced, with perhaps the Haskell Platform becoming the new
library
standardisation effort.
I thought the *eventual* plan was to pr
On Sat, May 01, 2010 at 08:05:58PM +0100, Simon Marlow wrote:
> On 01/05/10 17:16, Ian Lynagh wrote:
>
>>> So it seems this is closer to option (2) in my message, because
>>> portablebase and haskell2010 overlap, and are therefore mutually
>>> exclusive, whereas in (4) haskell2010 and base2010 are
On 30/04/10 23:52, Felipe Lessa wrote:
On Fri, Apr 30, 2010 at 09:37:39PM +0100, Simon Marlow wrote:
I like the picture where we have a small base, lots of independent
packages, and one or more haskell20xx packages that re-exports all
the standardised stuff from the other packages. This arrange
On 01/05/10 17:16, Ian Lynagh wrote:
So it seems this is closer to option (2) in my message, because
portablebase and haskell2010 overlap, and are therefore mutually
exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping -
that's the crucial difference.
If they are non-overlapp
On Fri, Apr 30, 2010 at 09:37:39PM +0100, Simon Marlow wrote:
> On 30/04/10 13:19, Malcolm Wallace wrote:
>>> 4. Provide a haskell2010 package and a base2010 package that
>>> re-exports all of base except the modules that overlap with
>>> haskell2010. You can either use haskell2010,
>>> haskell2010
On 30/04/10 13:19, Malcolm Wallace wrote:
4. Provide a haskell2010 package and a base2010 package that
re-exports all of base except the modules that overlap with
haskell2010. You can either use haskell2010,
haskell2010+base2010, or base. This is a bit like (1), but
avoids the need for shadowing
Malcolm Wallace schrieb:
> In many ways this corresponds to my preferred solution, although I would
> rephrase it thus:
>
> * Deprecate use of the "base" package, (I do not mean to remove "base",
> just to freeze it, and discourage its general use.)
> * Create a new "haskell2010" package
On Fri, Apr 30, 2010 at 8:19 AM, Malcolm Wallace
wrote:
> Because I suggest that "portablebase" re-export the "haskell2010" API in its
> entirety, it would be impossible to use both packages explicitly at the same
> time from a single module - users would need to choose one or the other.
Is the i
When you talk about the package "haskell2010" do you mean a package
named "haskell" with major version "2010" as in "haskell-2010" or a
package actually named "haskell2010"?
Regards,
Bas
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://ww
During the Haskell 2010 process the
committee agreed that the libraries in the report should be updated,
i think: if committee assignment turned out to be ambiguous, it should
be returned to committee. we can discuss it here but then committee
should make a clear decision
The committee's decis
3. allow packages to shadow each other, so haskell2010 shadows
base. This is a tantalising possibility, but I don't have
any idea what it would look like, e.g. should the client or
the package provider specify shadowing?
This sounds like a potentially complicated new mechanism, int
Hello Simon,
Friday, April 30, 2010, 1:42:33 PM, you wrote:
> During the Haskell 2010 process the
> committee agreed that the libraries in the report should be updated,
i think: if committee assignment turned out to be ambiguous, it should
be returned to committee. we can discuss it here but the
On Tue, Jul 14, 2009 at 01:57:34PM +0100, Ian Lynagh wrote:
> On Tue, Jul 14, 2009 at 12:23:51PM +0100, Duncan Coutts wrote:
> > On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote:
> > > On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote:
> > > >
> > > To take one example, since List w
On Tue, Jul 14, 2009 at 12:23:51PM +0100, Duncan Coutts wrote:
> On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote:
> > On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote:
> > >
> > > Specifically, I suggest:
> > >
> > > 4. Ixkeep as Data.Ix
> > > 5. Array
On Thu, Jul 16, 2009 at 4:36 AM, Simon Marlow wrote:
> On 15/07/2009 18:10, David Menendez wrote:
>>
>> On Wed, Jul 15, 2009 at 11:33 AM, Simon Marlow wrote:
>>>
>>> On 15/07/2009 15:54, Ian Lynagh wrote:
On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote:
>
> But there
Simon Marlow wrote:
> Ian Lynagh wrote:
>> Simon Marlow wrote:
>>> But there's a solution: we could remove the "standard" modules from
>>> base, and have them only provided by haskell-std (since base will just
>>> be a re-exporting layer on top of base-internals, this will be easy to
>>> do). Most
On 15/07/2009 18:10, David Menendez wrote:
On Wed, Jul 15, 2009 at 11:33 AM, Simon Marlow wrote:
On 15/07/2009 15:54, Ian Lynagh wrote:
On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote:
But there's a solution: we could remove the "standard" modules from
base, and have them only pr
On 15/07/2009 17:03, Mathias Stearn wrote:
Would it be possible for the language to require that implementations
support linking multiple versions of packages (at least base and
haskell-std) into a single running instance? That would solve the
issue of using two libs that depend on different vers
On Wed, Jul 15, 2009 at 11:33 AM, Simon Marlow wrote:
> On 15/07/2009 15:54, Ian Lynagh wrote:
>>
>> On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote:
>>>
>>> But there's a solution: we could remove the "standard" modules from
>>> base, and have them only provided by haskell-std (since
Would it be possible for the language to require that implementations
support linking multiple versions of packages (at least base and
haskell-std) into a single running instance? That would solve the
issue of using two libs that depend on different versions.
On Wed, Jul 15, 2009 at 10:54 AM, Ian
Simon Marlow wrote:
> On 15/07/2009 15:47, Sittampalam, Ganesh wrote:
>
>>> But there's a solution: we could remove the "standard" modules from
>>> base, and have them only provided by haskell-std (since base will
>>> just be a re-exporting layer on top of base-internals, this will be
>>> easy to
On 15/07/2009 15:54, Ian Lynagh wrote:
On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote:
But there's a solution: we could remove the "standard" modules from
base, and have them only provided by haskell-std (since base will just
be a re-exporting layer on top of base-internals, this w
On 15/07/2009 15:47, Sittampalam, Ganesh wrote:
But there's a solution: we could remove the "standard" modules from
base, and have them only provided by haskell-std (since base will
just be a re-exporting layer on top of base-internals, this will be
easy to do). Most packages will then have dep
On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote:
>
> But there's a solution: we could remove the "standard" modules from
> base, and have them only provided by haskell-std (since base will just
> be a re-exporting layer on top of base-internals, this will be easy to
> do). Most
Simon Marlow wrote:
> On 14/07/2009 15:04, Ian Lynagh wrote:
>> I'd suggest
>>
>> Haskell.V2010.Data.List (just re-exports from V2011 where
>> possible) Haskell.V2010.Prelude (just re-exports from V2011
>> where possible) Haskell.V2011.Data.List
>> Haskell.V2011.Prelude
>>
On 14/07/2009 15:04, Ian Lynagh wrote:
On Tue, Jul 14, 2009 at 07:48:36AM +0100, Sittampalam, Ganesh wrote:
I don't have any strong opinion about whether there should be a library
standard or not, but if there is a standard, how about putting the
entire thing (perhaps including the Prelude) unde
On Tue, Jul 14, 2009 at 07:48:36AM +0100, Sittampalam, Ganesh wrote:
>
> I don't have any strong opinion about whether there should be a library
> standard or not, but if there is a standard, how about putting the
> entire thing (perhaps including the Prelude) under the prefix
> Haskell2010. or si
On Tue, Jul 14, 2009 at 11:57:11AM +0400, Bulat Ziganshin wrote:
> Tuesday, July 14, 2009, 3:20:42 AM, you wrote:
>
> > We've been fortunate recently that, because the hierarchical modules
> > haven't been in the standard, we've been able to extend and improve them
> > without breaking compatibili
On Tue, Jul 14, 2009 at 12:23:51PM +0100, Duncan Coutts wrote:
> On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote:
> > On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote:
> > >
> > To take one example, since List was immortalised in the H98 report with
> > 104 exports, Data.List has
On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote:
> On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote:
> >
> > I'd advocate 4. That is, drop the ones that are obviously superseded.
> > Keep the commonly used and uncontroversial (mostly pure) modules and
> > rename them to use the ne
A natural "language" consists of a vocabulary of words, as well as a
grammar for stringing them together. If we omit the common basic
libraries from the language definition, then are we implicitly
reducing the common vocabulary, and encouraging dialects to appear?
If I see the function "s
Ian Lynagh wrote:
> On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote:
>>
>> I'd advocate 4. That is, drop the ones that are obviously superseded.
>> Keep the commonly used and uncontroversial (mostly pure) modules and
>> rename them to use the new hierarchical module names.
>>
>
> W
On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote:
>
> I'd advocate 4. That is, drop the ones that are obviously superseded.
> Keep the commonly used and uncontroversial (mostly pure) modules and
> rename them to use the new hierarchical module names.
>
> Specifically, I suggest:
>
>
On Mon, 2009-07-13 at 21:57 +0100, Duncan Coutts wrote:
> On Wed, 2009-07-08 at 15:09 +0100, Simon Marlow wrote:
>
> > I'm mainly concerned with projecting a consistent picture in the Report,
> > so as not to mislead or confuse people. Here are the options I can see:
>
> > 2. Just drop the ob
On Wed, 2009-07-08 at 15:09 +0100, Simon Marlow wrote:
> I'm mainly concerned with projecting a consistent picture in the Report,
> so as not to mislead or confuse people. Here are the options I can see:
> 2. Just drop the obvious candidates (Time, Random, CPUTime,
> Locale, Complex?), l
On 11/07/2009 11:54, Manuel M T Chakravarty wrote:
Ross Paterson:
On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:
1. Just drop the whole libraries section from the report. The
Report will still define the Prelude, however.
There will be some loose ends where the rest of the repor
On Fri, Jul 10, 2009 at 10:05:52AM +0100, Simon Marlow wrote:
> On 08/07/2009 22:45, Ian Lynagh wrote:
>> On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:
>>> 1. Just drop the whole libraries section from the report. The
>>> Report will still define the Prelude, however.
>>>
>>
Ross Paterson wrote:
The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16,
Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should move
to the Prelude when the non-library part of the FFI spec is incorporated
into the Report?
The Prelude specification imports Char
On Sat, Jul 11, 2009 at 08:54:14PM +1000, Manuel M T Chakravarty wrote:
> Ross Paterson:
>> The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16,
>> Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should
>> move to the Prelude when the non-library part of the FFI spe
Ross Paterson:
On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:
1. Just drop the whole libraries section from the report. The
Report will still define the Prelude, however.
There will be some loose ends where the rest of the report
refers to entities from these libraries,
Simon Marlow:
On 08/07/2009 22:45, Ian Lynagh wrote:
On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:
1. Just drop the whole libraries section from the report. The
Report will still define the Prelude, however.
I'm tending towards (1), mainly because it provides a clean brea
On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:
> 1. Just drop the whole libraries section from the report. The
> Report will still define the Prelude, however.
>
> There will be some loose ends where the rest of the report
> refers to entities from these libraries, e.g.
Simon Marlow wrote:
> Heinrich Apfelmus wrote:
>>
>> If I understand that correctly, this would mean to simply include the
>> particular version of a library that happens to be the current one at
>> the report deadline. In other words, the report specifies that say
>> version 4.1.0.0 of the base li
On 08/07/2009 22:45, Ian Lynagh wrote:
On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:
1. Just drop the whole libraries section from the report. The
Report will still define the Prelude, however.
I'm tending towards (1), mainly because it provides a clean break and is
like
On 09/07/2009 13:26, Bulat Ziganshin wrote:
Hello Simon,
Thursday, July 9, 2009, 3:46:31 PM, you wrote:
This would be a bold step, in that we would be effectively standardising
a lot more libraries than the current language standard. The base
package is a fairly random bag of library modules,
On 08/07/2009 19:41, Heinrich Apfelmus wrote:
Bulat Ziganshin wrote:
Simon Marlow wrote:
3. Update the libraries to match what we have at the moment.
e.g. rename List to Data.List, and add the handful of
functions that have since been added to Data.List. One
problem with
On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:
>
> 1. Just drop the whole libraries section from the report. The
> Report will still define the Prelude, however.
>
> I'm tending towards (1), mainly because it provides a clean break and is
> likely to be the least confusing fo
Heinrich Apfelmus wrote:
If I understand that correctly, this would mean to simply include the
particular version of a library that happens to be the current one at
the report deadline. In other words, the report specifies that say
version 4.1.0.0 of the base library is the standard one for 2010.
Bulat Ziganshin wrote:
> Simon Marlow wrote:
>
>> 3. Update the libraries to match what we have at the moment.
>> e.g. rename List to Data.List, and add the handful of
>> functions that have since been added to Data.List. One
>> problem with this is that these modules are then ti
Hello Simon,
Wednesday, July 8, 2009, 6:09:29 PM, you wrote:
> 3. Update the libraries to match what we have at the moment.
> e.g. rename List to Data.List, and add the handful of
> functions that have since been added to Data.List. One
> problem with this is that these modules
54 matches
Mail list logo
