My original goal in this thread was to explore a way to map module
identifiers to the locations of module implementations that
implementations can retrieve and compile with minimal user
intervention. We got sidetracked into grafting, and
I'd like to return to the original goal.
The big open
On 23 March 2005 13:11, Malcolm Wallace wrote:
I think this will be trivially possible once the compilers support
multiple versioning of packages. (Ghc may even support it already.):
{-# OPTIONS -package foo-1.0 #-}
module Old (module Foo) where
import Foo
{-# OPTIONS
S. Alexander Jacobson wrote:
As I move from machine to machine, it would be nice not to have to
install all the libraries I use over and over again. I'd like to be
able to do something like this:
import http://module.org/someLib as someLib
If the requested module itself does local
Dear list members,
I'd like to share some sketchy ideas I have on the subject to address
some of the issues raised.
At 12:14 22/03/05 +, Malcolm Wallace wrote:
I cannot see any of the Haskell compilers ever implementing this idea
as presented. It would introduce an enormous raft of
Hello
Here are some problems I see with the scheme:
1) No easy way of seing the dependencies of a single package.
Currently I can just look at the Cabal file and know what packages are
required. In the new scheme I would need to grep all the source files.
Not a very good improvement in my
S. Alexander Jacobson [EMAIL PROTECTED] writes:
Ok, well lets unpack what is actually required here:
1. Change of syntax in import statements
GHC already has lots of new syntax.
I can see that one might wish to broaden the import syntax, rather
like Hugs once supported (but not now) to use
Here is what I designed and implemented for my language Kogut:
There is a file format of compilation parameters (compiler options,
source file encoding, directories to look for interface files for
imported modules, directories to look for libraries, C libraries
to link, directories to look for
Switching to -cafe...
At 12:14 22/03/05 +, Malcolm Wallace wrote:
import http://domain.org/package-1.0.cabal#Network.HTTP as HTTP
import http://hage.org/package-2.1.cabal#Network.HTTP as HTTP2
--note use of HTTP fragment identifier for module name
I cannot see any of the Haskell
Proposal restatement:
Import statements should be allowed to include URL of Cabal packages.
Module namespace in these import statements should be with respect to
the package and not the local environment. e.g. these import
statements allow us to import two different versions of Network.HTTP
At 15:47 21/03/05 -0500, S. Alexander Jacobson wrote:
As I move from machine to machine, it would be nice not to have to install
all the libraries I use over and over again. I'd like to be able to do
something like this:
import http://module.org/someLib as someLib
If the requested module
S. Alexander Jacobson [EMAIL PROTECTED] writes:
Proposal restatement:
Import statements should be allowed to include URL of Cabal packages.
Module namespace in these import statements should be with respect to
the package and not the local environment. e.g. these import
statements
On Tue, 22 Mar 2005 06:40:02 -0500 (Eastern Standard Time), S.
Alexander Jacobson [EMAIL PROTECTED] wrote:
Proposal restatement:
Import statements should be allowed to include URL of Cabal packages.
Module namespace in these import statements should be with respect to
the package and not the
On 22 March 2005 13:03, Lemmih wrote:
On Tue, 22 Mar 2005 06:40:02 -0500 (Eastern Standard Time), S.
Alexander Jacobson [EMAIL PROTECTED] wrote:
I don't understand. Are you saying that there will be only one
Hackage server ever and it will have all information about all
packages everywhere
On Tue, 22 Mar 2005, Lemmih wrote:
The idea with Hackage was to create a central place for people to put
software or links to software, so keeping only one server for free (as
in beer) packages would be desirable. However, this does in no way
limit how Hackage can be used for private code
On Tue, 22 Mar 2005, Malcolm Wallace wrote:
Import statements should be allowed to include URL of Cabal packages.
Module namespace in these import statements should be with respect to
the package and not the local environment. e.g. these import
statements allow us to import two different versions
As I move from machine to machine, it would be nice not to have to
install all the libraries I use over and over again. I'd like to be
able to do something like this:
import http://module.org/someLib as someLib
If the requested module itself does local imports, the implementation
would
Greetings Alexander,
I have been thinking about something very much similar for some time.
But:
Am 21. Mrz 2005 um 21.47 Uhr schrieb S. Alexander Jacobson:
As I move from machine to machine, it would be nice not to have to
install all the libraries I use over and over again. I'd like to be
the concept of adapters. In particular, I'd really like a
way to make sure that Prelude.read does not produce an error when the
saved representation of a datatype differs from the current one.
Manual management is a big PITA. (And yes, this too is orthogonal from
the question of URLs in haskell
On Mon, 21 Mar 2005 23:06:25 +0100, Sven Moritz Hallberg [EMAIL PROTECTED]
wrote:
Greetings Alexander,
I have been thinking about something very much similar for some time.
But:
Am 21. Mrz 2005 um 21.47 Uhr schrieb S. Alexander Jacobson:
As I move from machine to machine, it would be
Lemmih,
The current Haskell/Cabal module and packaging system is substantially
annoying for the typical non-sysadmin end-user. In particular, if
they move their code to another machine they have to do a bunch of
different administrivia including:
1. knowing the source package for each
On Mon, 21 Mar 2005 22:06:25 -0500 (Eastern Standard Time), S.
Alexander Jacobson [EMAIL PROTECTED] wrote:
Lemmih,
The current Haskell/Cabal module and packaging system is substantially
annoying for the typical non-sysadmin end-user. In particular, if
they move their code to another machine
21 matches
Mail list logo
