On Wed, Jul 05, 2006 at 01:03:01AM +0100, Brian Hulley wrote:
Simon Peyton-Jones wrote:
Concerning other mail on this subject, which has been v useful, I've
revised the Wiki page (substantially) to take it into account.
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
Further input
Brian Hulley [EMAIL PROTECTED] writes:
because if the suggested syntax is used, import directives come in two
flavours: ones that use from to import from a different package and
ones that don't use from and therefore must refer to the current
package.
What is the current package? My
Ian Lynagh wrote:
I think I missed where the plan to use quotes came from. What's the
purpose? Package names already have a well-defined syntax with no spaces
or other confusing characters in them, so why do we need the quotes? Or
is it just so we can have packages with the same name as
Ketil Malde wrote:
What is the current package?
The package that you're currently compiling. This now must be known at
compile time.
My impression was that from would
only be needed when there was ambiguity. (And if I wanted to type
myself to death, I'd be using Java :-) If you *have*
So here are some options:
1. the proposal as it is now, keeping exposed/hidden state in the
package database, don't support available
2. Add support for available. Cons: yet more complexity!
3. Drop the notion of exposed/hidden, all packages are available.
(except for
Niklas Broberg wrote:
So here are some options:
1. the proposal as it is now, keeping exposed/hidden state in the
package database, don't support available
2. Add support for available. Cons: yet more complexity!
3. Drop the notion of exposed/hidden, all packages are
| So instead of just taking this simple solution, the wiki proposal is
instead
| destroying the beauty of the per-package namespace idea by
incorporating
| into it the existing shared namespaces with their attendant problems,
| instead of just letting the existing messy system die a natural death
Hi Folks,
As you may know, support on MacOS X/PowerPC hardware has been lacking a
bit recently: there are outstanding showstoppers with 6.4.2. Our Mac
hero Wolfgang Thaller has been busy, and hasn't had time to look into
the problems or package 6.4.2 for MacOS X (at least I assume he's busy,
Simon Marlow wrote:
In fact, we can imagine three states that a package could be in:
- exposed: the package's modules populate the global module namespace,
explicit from imports may be used to resolve ambiguity
- hidden: the package cannot be used at all
- available: the package can
X (at least I assume he's busy,
that's the last I heard, but he didn't respond to my latest ping).
Oops, sorry about that. Yes, I'm quite busy, trying to get a degree
here.
Proper Mac OS X support will resume on September 1st :-).
So the mantle of powerpc-apple-darwin maintainer is
Dimitry Golubovsky wrote:
I'd suggest the following sub-definition for available (other name
could be transient):
A package which is available is not installed at (immediately
known to) a particular developer's system, as opposed to exposed and
hidden which are installed.
When a
Simon,
I submitted a patch for ticket #766 this afternoon.
I've banged my head on ticket #751, building with debugging symbols
and running under gdb, but have yet to get any useful information that
would pin down the bug.
Best,
Greg
On Jul 5, 2006, at 10:47 AM, Simon Marlow wrote:
Hi
Simon Peyton-Jones wrote:
So instead of just taking this simple solution, the wiki proposal is
instead destroying the beauty of the per-package namespace idea by
incorporating into it the existing shared namespaces with their
attendant problems, instead of just letting the existing messy
system
Package names should never appear in source files IMHO. if a package
name is in the source file, then you might as well make it part of the
module name. packages exist for 'meta-organization' of code. A way to
deal with mapping code _outside_ of the language itself, putting
packages inside the
14 matches
Mail list logo
