Wrong namespace! Could you please, move your further discussion
on this subject to [EMAIL PROTECTED]? You pauperize the
other archive while polluting this one.
Jan
___
Haskell mailing list
[EMAIL P
Wed, 28 Feb 2001 17:31:13 +0100, Christian Brolin <[EMAIL PROTECTED]> pisze:
> This dilemma comes from the fact that you don't tell the compiler what
> module to compile, but just give it some Haskell code. You should always
> compile the module with:
> compile A.B.C.D, i.e. tell the compiler whi
Marcin 'Qrczak' Kowalczyk wrote:
>
> Wed, 28 Feb 2001 11:44:58 +0100, Christian Brolin <[EMAIL PROTECTED]> pisze:
>
> > > It does not. File A/B/C/D.hs can be module A.B.C.D, or module B.C.D which
> > > happened to be placed in a directory A, or C.D etc. It's ambiguous.
> >
> > Only if you give t
Wed, 28 Feb 2001 11:44:58 +0100, Christian Brolin <[EMAIL PROTECTED]> pisze:
> > It does not. File A/B/C/D.hs can be module A.B.C.D, or module B.C.D which
> > happened to be placed in a directory A, or C.D etc. It's ambiguous.
>
> Only if you give the compiler include pathes to both ~ and ~/A, w
Marcin 'Qrczak' Kowalczyk wrote:
>
> On Wed, 28 Feb 2001, Christian Brolin wrote:
>
> > What?? The compiler knows the full name of the module without the module
> > clause.
>
> It does not. File A/B/C/D.hs can be module A.B.C.D, or module B.C.D which
> happened to be placed in a directory A, or
On Wed, 28 Feb 2001, Christian Brolin wrote:
> What?? The compiler knows the full name of the module without the module
> clause.
It does not. File A/B/C/D.hs can be module A.B.C.D, or module B.C.D which
happened to be placed in a directory A, or C.D etc. It's ambiguous.
I'm not saying that I w
Malcolm Wallace wrote:
>
> Christian writes:
> > What about the module declaration? Should it be:
> > module Text.Xml.Parser where ...
> > or just
> > module Parser where ... -- located in Text/Xml/Parser.hs?
>
> The former. The reason is that a compiler needs to generate a unique
> linker
At 2001-02-26 09:59, Malcolm Wallace wrote:
>Proposal 2
>--
>Adopt a standardised namespace layout to help those looking for or
>writing libraries,
I'm a big fan of the Java reversed DNS style. Whatever, I think it's
important that anyone with a domain name should be able to obtain a
Malcolm Wallace wrote:
>
> Proposal 1
> --
> Introduce nested namespaces for modules. The key concept here is to
> map the module namespace into a hierarchical directory-like structure.
> I propose using the dot as a separator, analogous to Java's usage
> for namespaces.
I haven't comme
Malcolm Wallace wrote:
>
> I propose that every import have an implicit "as"
> clause to use as an abbreviation, so in
> import qualified Text.Xml.Parse [ as Parse ]
> the clause "as Parse" would be implicit, unless overridden by the
> programmer with her own "as" cl
I have two nitpicking comments.
Malcolm Wallace wrote (on 26-02-01 17:59 +):
> * The use of qualified imports becomes more verbose: for instance
> import qualified XmlParse
> ... XmlParse.element f ...
> becomes
> import qualified Text.Xml.P
Malcolm Wallace schrieb folgendes am Mon, Feb 26, 2001 at 05:59:30PM +:
> Proposal 2
> --
> but only a guaranteed-to-be-stable, complete, library could be called
>
> Std.Text.Xml
>
> The implication of the Std. namespace is that all such "standard"
> libraries will be distributed
Malcolm Wallace <[EMAIL PROTECTED]> writes:
> Proposal 1
> --
> Introduce nested namespaces for modules. The key concept here is to
> map the module namespace into a hierarchical directory-like structure.
> * The use of qualified imports becomes more verbose: for instance
[...]
This is an annoucement of a new mailing list, and a proposal for
three things:
* An extended mechanism for module namespaces in Haskell.
* A "standard" namespace for new libraries, common across all systems.
* A social process for adding new libraries to the "standard" set.
A formatted
14 matches
Mail list logo