On 2006-02-21, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 21. Februar 2006 04:41 schrieb John Meacham:
>> on this note, I thought it would be nice to do a 'mostly unqualified'
>> import.
>>
>> import Foo qualified(foo,bar)
>>
>> which will have the effect of
>>
>> import Foo hiding(
On Thu, 2006-02-23 at 21:04 +0100, Marcin 'Qrczak' Kowalczyk wrote:
> "Simon Marlow" <[EMAIL PROTECTED]> writes:
>
> > The main difference is that I'm doing away with parentheses, commas, and
> > export specifiers, and using layout and full declaration syntax instead.
> > (I don't really want to d
On Thu, Feb 23, 2006 at 10:58:36AM +, Malcolm Wallace wrote:
> Some data-structures people (e.g. Chris Okasaki) are of the opinion that
> lists tend to be over-used (because they are built-in), when other
> datatypes might be much more appropriate.
While this may be true of lesser languages an
let's go through 5.2 "Export Lists" to see what would be missing
if we tried to replace the export list with a separation of a module
into a public (exported) and a private (local) part:
---
module M
exports
where
--
1. "value, field name, or c
On Thu, Feb 23, 2006 at 11:36:34AM +0100, Wolfgang Jeltsch wrote:
> The remaining problem is that using "type" for every type is misleading,
> since
> "type" is otherwise used only for aliases. Maybe it would be better to use
> something like "typealias" for type aliases, since using "type" for
On 2/23/06, Ben Rudiak-Gould <[EMAIL PROTECTED]> wrote:
> In fact, this suggests a compromise: how about implicitly importing the
> Prelude only if the module header is omitted? That way there'll be no impact
> on short (single-module) programs.
+1
--
Taral <[EMAIL PROTECTED]>
"Computer science i
I wrote:
What I don't like is that given a signature like
x :: a -> a
there's no way to tell, looking at it in isolation, whether a is free or
bound in the type. [...]
Here's a completely different idea for solving this. It occurs to me that
there isn't all that much difference between
Wolfgang Jeltsch wrote:
Maybe it would be better to use
something like "typealias" for type aliases, since using "type" for declaring
type aliases is misleading anyway.
I would be happy if "type" were returned to the pool of usable identifiers.
The other name I frequently wish I could use is
Malcolm Wallace wrote:
An explicit interface would be useful for many purposes besides
machine-checked documentation. For instance, it could be used to
eliminate the hs-boot or hi-boot files used by some compilers when
dealing with recursive modules.
Why *does* ghc require hs-boot files? What
Hello Claus,
Thursday, February 23, 2006, 9:48:03 PM, you wrote:
CR> if you'd go one step further, you'd replace the public/private modifiers
CR> with public/private module sections. I don't like the modifiers, and I'm
CR> uncertain about the intermediate form you suggested, but I might be
CR> a
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> The main difference is that I'm doing away with parentheses, commas, and
> export specifiers, and using layout and full declaration syntax instead.
> (I don't really want to discuss this very rough idea any more though,
> it's just a distraction, and I'
Malcolm Wallace wrote:
Yes, many trivial programs would acquire one extra import
decl - is that such a big deal?
No, but overall it feels like a slight loss, because I'd expect the modules
that gained a line to be shorter on average, and adding a line to a shorter
module seems like a bigger d
modules M exports
class Eq a where
(==) :: a -> a -> Bool
data T :: * -> *
f :: T -> Int
mkT :: Int -> T
where -- implementation below here
--
SM> The main difference is that I'm doing away with parentheses, commas, and
SM> export specifiers, and using la
John Hughes wrote:
>
> Type signatures currently do more than state the type of a variable.
> They potentially (i) enable polymorphic recursion, and (ii) disable the
> monomorphism restriction, thus losing sharing. It would be very strange
> if a type signature *in an export list* were to
"Simon Marlow" <[EMAIL PROTECTED]> wrote:
> >>> However, I would be
> >>> equally happy to combine type/newtype/data into a single keyword
> >>> for exports.
>
> In fact, a keyword is unnecessary, as long as classes are identified
> with the 'class' keyword, there's no need to tag type constructo
On Thursday 23 February 2006 09:53, Ketil Malde wrote:
> Wolfgang Jeltsch <[EMAIL PROTECTED]> writes:
> >> Personally, I would greatly prefer to have libraries that do not
> >> clash with common Prelude functions.
> >
> > I would solve this problem by reducing the Prelude to just a core.
> > List
Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> MW> With my proposal, you would simply replace the
> MW> implicit "import Prelude" with an explicit "import
> MW> Prelude.Standard"
>
> import Prelude ($)
> can't solve this problem?
One of the problems with the current mechanism for overriding Prelud
Hello John,
Thursday, February 23, 2006, 4:07:52 PM, you wrote:
JM> That is the plan. none of the current Array implementations will
JM> change, they will still be instances of both MArray and HasBounds. it is
JM> just that HasBounds will no longer be a superclass of MArray, however
JM> that does
On Wed, Feb 22, 2006 at 05:12:47PM +, Malcolm Wallace wrote:
> Everything else that is currently in the Haskell'98 Prelude is
> re-distributed across a variety of small modules. Where a syntactic
> desugaring rule currently uses an entity from the Prelude, the new
> interpretation is that it u
On Thu, Feb 23, 2006 at 03:26:56PM +0300, Bulat Ziganshin wrote:
> SM> I've added a ticket, scheduled for 6.6.
>
> i just want to mention that current implementation is faster than this
> general one and enough for most of usages. so it will be great to make
> more general interface but use old im
Hello Simon,
Thursday, February 23, 2006, 2:41:11 PM, you wrote:
>>> modules M exports
>>>
>>> class Eq a where
>>> (==) :: a -> a -> Bool
>>>
>>> data T :: * -> *
>>> f :: T -> Int
>>> mkT :: Int -> T
>>>
>>> where -- implementation below here
>>> --
SM>
Hello Simon,
Thursday, February 23, 2006, 1:56:03 PM, you wrote:
>> We could fix it fairly easily, we just need to get rid of HasBounds
>> as a superclass of MArray and add a new method 'getBounds' that
>> returns the bounds in the monad and then modify the default methods
>> to use getBounds rat
Hello Simon,
Thursday, February 23, 2006, 2:21:22 PM, you wrote:
SM>ghc --make My.Dotted.Module.hs Main.hs
SM> works fine. Similarly with GHCi.
i don't known that. we should add this to faq
SM> It's only when GHC has to actually *find* a source file for a module
SM> that the hierarchical
Hello Malcolm,
Thursday, February 23, 2006, 1:58:36 PM, you wrote:
MW> People often overlook the useful facility of the module system to group
MW> multiple common imports into a single re-exporting super-module. With
MW> my proposal, you would simply replace the implicit "import Prelude" with
MW
Malcolm Wallace <[EMAIL PROTECTED]> writes:
> you would simply replace the implicit "import Prelude" with
> an explicit "import Prelude.Standard" (or use a build flag like
> -fimplicit-prelude, or +98).
Why not keep it implicit? If you want the alternative behavior, you
know where to get it (imp
Subject: Re: Export lists in modules
Type signatures currently do more than state the type of a variable.
They potentially (i) enable polymorphic recursion, and (ii) disable the
monomorphism restriction, thus losing sharing. It would be very strange
if a type signature *in an export list*
On 23 February 2006 11:14, Malcolm Wallace wrote:
> "Simon Marlow" <[EMAIL PROTECTED]> wrote:
>
>>> However, I would be
>>> equally happy to combine type/newtype/data into a single keyword for
>>> exports.
>>
>> for the record, I am in favour of tagging export specifiers with
>> 'class' or 'type
On 23 February 2006 11:14, Malcolm Wallace wrote:
> "Simon Marlow" <[EMAIL PROTECTED]> wrote:
>> If modules are to contain interfaces, I don't
>> think extending the export list is the way to do it. I'd rather do
>> something like: --
>> modules M exports
>>
On 22 February 2006 14:55, Ben Rudiak-Gould wrote:
> Simon Marlow wrote:
>> there's a lack of modularity in the current
>> design, such that renaming the root of a module hierarchy requires
>> editing every single source file in the hierarchy. The only good
>> reason for this is the separation be
On 22 February 2006 13:09, David Roundy wrote:
> On Tue, Feb 21, 2006 at 03:50:29PM +, Henrik Nilsson wrote:
>> I'm already somewhat unhappy about the way most present Haskell
>> tools map module names to path names (I'd generally prefer to have
>> the possibility to flatten my file hierarchie
"Simon Marlow" <[EMAIL PROTECTED]> wrote:
> > However, I would be
> > equally happy to combine type/newtype/data into a single keyword for
> > exports.
>
> for the record, I am in favour of tagging export specifiers with
> 'class' or 'type' (using 'type' for all type constructors, in light of
> y
On 23 February 2006 10:28, Jean-Philippe Bernardy wrote:
> I lost track of what is the issue being tackled here. What's broken
> with the current way of specifying exported entities? Imho it's the
> best system that I've seen (across all languages I know).
>
> A lot of language chose to separate
Georg Martius wrote:
> Okay, I see the point of not including the environment into the spec. However
> other languages like Java for example do this as far as I know.
To be precise, no, the Java specs leave this to the implementation:
JLS - 7.2. host support for packages
Each host determines h
Ketil Malde <[EMAIL PROTECTED]> wrote:
> > I would solve this problem by reducing the Prelude to just a core.
> > List function could go, for example, (mostly) into Data.List.
>
> If this means that you must import Data.List almost everywhere, this
> won't change anything - only add yet another
On 23 February 2006 01:24, John Meacham wrote:
> On Wed, Feb 22, 2006 at 06:47:19PM +, Ben Rudiak-Gould wrote:
>> While we're on the topic, I have a couple of problems with the
>> current array system that cut deeper than the naming:
>>
>> * The function for getting the bounds of an MArra
On 22 February 2006 22:04, Malcolm Wallace wrote:
> Wolfgang Jeltsch <[EMAIL PROTECTED]> writes:
>
>>> module Prelude.Standard
>>> ( module Prelude
>>> , module Prelude.Num
>>> , module Prelude.Comparison
>>> , module Prelude.Monad
>>> , module Prelude.List
>>> , module Pr
Am Donnerstag, 23. Februar 2006 02:47 schrieb John Meacham:
> [...]
> But more importantly, The haskell module system has a nice philosophy of
> just being about controlling the namespace of what is in scope in a
> module. Conflating representation details with it would just confuse
> things. I'd
I lost track of what is the issue being tackled here. What's broken
with the current way of specifying exported entities? Imho it's the
best system that I've seen (across all languages I know).
A lot of language chose to separate interface from implementation in
source files. (eg. Ada) I find thi
On 22 February 2006 17:27, Malcolm Wallace wrote:
> However, I would be
> equally happy to combine type/newtype/data into a single keyword for
> exports.
for the record, I am in favour of tagging export specifiers with 'class'
or 'type' (using 'type' for all type constructors, in light of yours a
On 23 February 2006 01:48, John Meacham wrote:
> On Wed, Feb 22, 2006 at 05:11:26PM -, Simon Marlow wrote:
>> Indeed, the distinction between data & newtype should be a completely
>> private property, so we certainly shouldn't distinguish those in
>> exports/imports. It's less clear to me whe
Wolfgang Jeltsch <[EMAIL PROTECTED]> writes:
>> Personally, I would greatly prefer to have libraries that do not clash
>> with common Prelude functions.
> I would solve this problem by reducing the Prelude to just a core. List
> function could go, for example, (mostly) into Data.List.
If this
41 matches
Mail list logo
