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
om the point of view of the Haskell report - I can
> certainly update the report to use the hierarchical module names, but
> that presents us with one or two problems in the implementation.
>
> However, what happens when someone wants to write some code that uses
> Haskell 2010 libr
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
s to write some code that uses Haskell 2010
libraries, but also uses something else from base, say
Control.Concurrent? The modules from haskell2010 overlap with those
from base, so all the imports of Haskell 2010 modules will be ambiguous.
The Prelude is a bit of a thorny issue too: currently it i
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
Bulat Ziganshin wrote:
> Hello Ganesh,
>
> Tuesday, July 14, 2009, 11:59:00 AM, you 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
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
Hello Ganesh,
Tuesday, July 14, 2009, 11:59:00 AM, you 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
Bulat Ziganshin wrote:
> Hello Ganesh,
>
> Tuesday, July 14, 2009, 10:48:36 AM, you 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
>
Hello Ian,
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 compatibility with the language definition.
but breaking compatibility wi
Hello Ganesh,
Tuesday, July 14, 2009, 10:48:36 AM, you 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 similar? M
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 Thu, Jul 9, 2009 at 5:15 AM, Brandon S. Allbery
KF8NH wrote:
> On Jul 8, 2009, at 17:55 , Bulat Ziganshin 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 Prel
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,
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, for instance. It
The base library is
On Jul 8, 2009, at 17:55 , Bulat Ziganshin 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
a
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 conf
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
Hello Isaac,
Wednesday, July 8, 2009, 11:05:44 PM, you wrote:
> It could be a mere informative reference: "the most-community-accepted
> libraries at the time of publication are:".
no, i mean that if we include some library in Haskell-2010, then it
means that any compiler declared as H2010-compl
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.
Hello Heinrich,
Wednesday, July 8, 2009, 10:41:34 PM, you 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 o
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
This is more of a consistency issue than anything else. We have to
decide what to do with the libraries in the Report.
Right now, the Haskell Report specifies 15 library modules. Things like
Maybe, Char, IO, Time, and Random. The situation is not ideal, for many
reasons:
- There are a lo
67 matches
Mail list logo
