John Meacham wrote:
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
Malcolm Wallace [EMAIL PROTECTED] writes:
One of the problems with the current mechanism for overriding Prelude
definitions, is that every module that /uses/ such an entity must
also explicitly hide the original Prelude:
I guess I don't quite understand what you are trying to achieve.
Case
Benjamin Franksen [EMAIL PROTECTED] writes:
If this means that you must import Data.List almost everywhere, this
won't change anything - only add yet another import to every file.
But you could import something different instead!
Yes. You can do that as it is, of course (well, more or less,
From: Claus Reinke [EMAIL PROTECTED]
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:
...
any other issues I missed here?
I feel unkeen.
One
Axel Simon wrote:
One of the nice things about Haskell is that definitions can appear in any
order. That makes it possible to gather a group of logically related
definitions together, within a module. With your proposal, exported
definitions and non-exported ones would have to be
I feel unkeen.
you will notice that I haven't actually proposed adopting this (yet:-);
neither did Simon M for his original version. so far, I had thought
Haskell's export/import language quite limited, but useable and simple.
so apart from fixing the asymmetries between export and import, and
On 2/24/06, John Hughes [EMAIL PROTECTED] wrote:
From: Claus Reinke [EMAIL PROTECTED]
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:
These days, hs-boot files are pretty close to source files, with masses
of stuff omitted.
However, you must process the import declarations of the hs-boot file to
figure out the name spaces involved. In the original source file, you
can't process the import declarations because those modules
On Fri, Feb 24, 2006 at 12:13:14PM -, Simon Peyton-Jones wrote:
You could imagine
a) compiling recursive groups all at once
b) somehow magically filtering the source file to omit anything
undefined, leaving only defined stuff. which ought to be enough to
tie the knot.
jhc does a,
Hello Claus,
Friday, February 24, 2006, 2:46:40 PM, you wrote:
CR yes, this would add one constraint on where to place definitions. but
CR grouping logically related definitions together is not quite what one
CR might think anyway: aren't the definitions making up the interface
CR most strongly
so:
not quite (though I believe that would be close to Simon M's idea).
in my modification, both map and length would move completely
into the export section, length# would stay in the local section.
both sections would just be module bodys., containing full
definitions, declarations, imports.
On Friday 24 February 2006 16:38, Bulat Ziganshin wrote:
i personally prefer to have
public/private modifiers on each function and gather interface
documentation by tools like haddock
Me too.
Ben
___
Haskell-prime mailing list
On 2/24/06, Benjamin Franksen [EMAIL PROTECTED] wrote:
On Friday 24 February 2006 16:38, Bulat Ziganshin wrote:
i personally prefer to have
public/private modifiers on each function and gather interface
documentation by tools like haddock
Me too.
Maybe if you only had to specify which
Bulat.Ziganshin responded to Claus Reinke:
CR yes, this would add one constraint on where to place definitions. but
CR grouping logically related definitions together is not quite what one
CR might think anyway: aren't the definitions making up the interface
CR most strongly related,
i personally prefer to have
public/private modifiers on each function and gather interface
documentation by tools like haddock
Me too.
having to type one of public or private at each
function site would get really tedious...
you mean as in public static void main(String[] args) { ..}
Hello Claus,
Friday, February 24, 2006, 6:55:51 PM, you wrote:
CR not quite (though I believe that would be close to Simon M's idea).
CR in my modification, both map and length would move completely
CR into the export section
WHY? it's not the interface. implementation of exported functions is
Hello Claus,
Friday, February 24, 2006, 7:53:09 PM, you wrote:
CR public class C a
CR where
CR public m1 :: a
CR private m2 :: a - String
please don't stop on this!
public map (private f) (public (private x:public xs)) =
private (public f (private x))
`public :`
And this
public foldr:: (a - b - b) - b - [a] - b
public foldr f z [] = z
public foldr f z (x:xs) = f x (foldr f z xs)
or is it
public foldr:: (a - b - b) - b - [a] - b
foldr f z [] = z
foldr f z (x:xs) = f x (foldr f z xs)
and now things aren't lined up.
what about method and data constructors?
data public: Foo a = private: Bob | public: Baz
class Foo a where
private:
foo :: a
public:
baz :: a
I really like haskell's current module system. A whole lot. other than
the minor tweaks that have been mentioned. A
On 23/02/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
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
20 matches
Mail list logo
